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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document describes the basic data transport functions of the Data Link Control (DLC) layer for fixed 
wireless access systems above 11 GHz according to the High Performance Radio Access (HIPERACCESS) project. 
Separate ETSI documents provide details of the system overview, the PHYsical (PHY) layer, the Convergence Layer 
(CL) and the conformance test requirements defined for HIPERACCESS. 

For the purpose of the present document, a "system" constitutes the PHY and DLC layers, which are independent of the 
core network, and the core network specific convergence layers. It should be noted that to specify a complete system, 
other specifications, e.g. for the network layer and higher layers are required. These specifications are assumed to be 
available or to be developed by other bodies. 



Introduction 

The main field of application of HIPERACCESS systems is to provide access to a broad range of core networks 
including ATM, IP, PSTN, PDN, etc. By means of a Point-to-Multipoint (PMP) architecture the network service area 
may cover scattered subscriber locations. The systems may be applied to build new access networks by means of a 
multi -cellular architecture, covering both suburban, urban and regional areas. 

Subscribers are offered the full range of services by the particular public or private network. Subscribers will have 
access to these services by means of the various standardized user network interfaces. HIPERACCESS systems provide 
standard network interfaces and transparently connect subscribers to the appropriate network node. These systems allow 
a service to be connected to a number of subscribers ranging from a few to several thousand, and over a wide range of 
distances, e.g. up to 2 km to 5 km. 

The essential features of a HIPERACCESS system are: 

• efficient use of the radio spectrum; 

• high multiplex gain; 

• maintaining QoS. 

Radio is often the ideal way of obtaining communications at low cost and difficult topography. Moreover, a small 
number of sites are required for these installations, thus facilitating rapid implementation and minimizing maintenance 
requirements of the systems. 

Multiplexing means that m subscribers can share n radio channels (m being larger than n), allowing a better use to be 
made of the available frequency spectrum and at a lower equipment cost. The term "multi-access" derives from the fact 
that every subscriber has access to every channel (instead of a fixed assignment as in most multiplex systems). When a 
call or service is initiated the required resource is allocated to it. When the call or service is terminated, the resource is 
released. Concentration requires the use of distributed intelligent control which in turn allows many other operations 
and maintenance functions to be added. 

Maintenance of QoS means that the exchange (service node) and the subscriber equipment can communicate with each 
other without being restricted by the actual quality of the radio link. 
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The implementation of an HIPERACCESS system includes at least one subscriber unit (referred to as terminal or 
Access Termination, AT) that communicates with a base station (referred to as Access Point, AP) via an interoperable 
air-interface, the interfaces to external networks, and services transported by the DLC and PHY protocol layers. 
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1 Scope 

The present document applies to the HIPERACCESS air-interface with the specifications of layer 2 (Data Link Control 
(DLC) layer) following the ISO-OSI model. HIPERACCESS is confined to only the radio subsystem consisting of the 
physical (PHY) layer and the DLC layer, which are both core network independent, and the core network specific 
convergence sublayer. 

The DLC layer contains functions and protocols for: 

• Radio link control (RLC) for managing the resources of both directions of the radio link between AP and AT, 
including: 

Initialization Control (IC), for managing the access of a terminal to the HIPERACCESS system; 

Radio Resource Control (RRC), for managing adaptive PHY mode operation, adaptive power control, 
load levelling, etc.; 

Connection Control (CC), for managing the setup and the quality of connections; 
Security Control (SC), for managing privacy of traffic data and terminal authentication. 

• Medium Access Control (MAC) for managing the access to the shared radio resource, including Resource 
Grant Control (RGC) and the control of the frame structure. 

• The interworking with layers at the top of the radio subsystem is handled by convergence layers above the 
DLC layer. The scope of the present document is as follows: 

it gives a description of the basic data transport functions of the DLC layer of HIPERACCESS systems; 

it specifies the protocols (including all messages and their formats) in full detail in order to allow 
interoperability between equipment developed by different manufacturers. 

For the purpose of interoperability and completeness the present document includes the detailed specification of the 
normal and exceptional behaviour. ASN.l is used for the description of the content of all protocol primitives 
(normative) and service primitives (informative), a graphical view of the message flow over interfaces is provided by 
the use of MSCs (informative) and HMSCs (informative) and the protocol and system behaviour is extensively 
specified in SDL (normative). 

The present document does not address the requirements and technical characteristics for conformance testing. These 
are covered in separate deliverables. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox. etsi.org/Reference . 

[1] ETSI TS 101 999: "Broadband Radio Access Networks (BRAN); HIPERACCESS; PHY protocol 

specification". 

[2] ETSI TR 102 003: "Broadband Radio Access Networks (BRAN); HIPERACCESS; System 

Overview". 
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network". 
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3 



Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

Access Point (AP): generalized equipment consisting of an Access Point Controller (APC) and several Access Point 
Transceivers (APT) 

NOTE 1 : Also addressed as base station. 

NOTE 2: A typical configuration is one APC per cell and one APT per RF channel. 

Access Terminal (AT): generalized equipment consisting of an Radio Termination (RT, transceiver) and Interworking 
Function (IWF) 

NOTE 1 : The number of ATs per RF channel and per sector is limited to 254. 

NOTE 2: An AT can only transmit and receive on a single RF channel, but can be switched from one RF channel to 
another one by the load-levelling procedure (non-seamless handover). 

authentication: method to prove the claimed identity of the communication partner 

NOTE: The AT shall be authenticated against the AP. 

burst: generic term for DL burst or UL burst, describing a sequence of channel symbols consisting of guard periods at 
beginning and end (only for UL), a preamble and the data symbols 

NOTE: A burst transports one or several MAC PDUs with a given PHY mode, i.e. different PHY modes within a 
burst are excluded. The data part contains one or several FEC blocks (where each FEC block shall have 
its own trellis termination if applicable and padding bits to complete a modulation symbol). 

• DL burst: Is present only in the optional TDMA zone of the DL frame. It contains FEC blocks of a specific 
PHY mode, i.e. the DL burst corresponds to a PHY mode region plus the preamble of that PHY mode region. 
A DL burst can serve several ATs. Several DL bursts with the same PHY mode can appear in the TDMA zone 
of one DL frame. 

• UL burst: Applies for all transmissions in the UL. The UL burst shall be preceded by a guard time required 
for power ramp-up at the AT. An UL burst can contain up to several FEC blocks or in the shortest case only 
one short MAC signalling PDU. An UL burst can contain either one preamble at the beginning after the guard 
time or several preambles (i.e. one midamble per FEC block). 
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cell: term with two different meanings: 

• (ATM) cell: a data unit referenced by the cell-based CL for ATM networks 

• (Geographical) cell: a geographical area controlled by an 

NOTE: A geographical cell can be split into several sectors, where this split could be different for different 
RF channels at the same cell site. 

certificate: secure binding between the identity and the public key of an AT 

cluster: set of cells where all frequencies available to the operator are used 

control zone: part of the DL frame, that consists of the DL map, the UL map, the ARQ map and some further signalling 
fields. 

DownLink (DL): the direction from AP to AT 

FEC block: result from the inner convolutional encoding (if applicable) of one RS codeword, including the trellis 
termination bits and further padding bits to complete a modulation symbol 

NOTE: If no inner convolutional code is present, the FEC block shall be simply identical to the RS codeword 

plus the padding bits. Hence, a FEC block carries one or up to four MAC PDUs. This applies both for DL 
and UL transmissions (except for the protection of the control zone in the DL and the short MAC 
signalling PDU in the UL). 

frame: sequence of data stream with a fixed duration of 1 ms 

NOTE 1 : The frame structure appears both in PHY and DLC layer. 

NOTE 2: The frame structure is different for FDD and TDD mode: 

• FDD Frame: the frames appear both in DL and UL with the same fixed length and DL frames and UL frames 
are synchronized with a fixed offset between them: 

DL frame: it consists in this order of a preamble, a control zone, a TDM zone, and optionally a TDMA 
zone and some padding symbols if necessary; 

UL frame: it consists of a number of short signalling bursts, long signalling bursts and data bursts in any 
order. 

• TDD frame: it consists of two subframes for DL and UL transmissions. 

General Broadcast Information (GBI or RlcGeneralBroadcastlnf ormation) message: broadcast message 
that is transmitted occasionally, i.e. not in every DL frame, containing several broadcast information fields (which are 
not that time-critical as the broadcast information fields in the control zone) and the PHY mode set descriptor (PSD) 

NOTE: During the transition phase from one PHY mode set to another PHY mode set, the GBI carries two PSDs. 

guard time: generic term for: 

• "Normal" guard time: time at the beginning and end of each UL burst to allow power ramping up and down 
at the AT; 

• Extended guard time (EGT): time required (e.g. for the ranging UL burst to compensate for the maximum 
round-trip delay (RTD), where the RTD = 2*TD depends on the location of the AT within the sector (the 
Transmission Delay TD is half of the RTD). The EGT shall be defined by an AT at the sector border. The 
EGT is known at the AP according to the radius of the sector. Each AT only knows its own RTD but not the 
EGT. 

NOTE: The EGT shall be defined by an AT at the sector border. The EGT is known at the AP according to the 
radius of the sector. Each AT only knows its own RTD but not the EGT. 

H-FDD AT: FDD AT transmitting and receiving data not simultaneously 

NOTE: DL and UL carriers are separated in frequency (paired bands). This is referred to as H-FDD operation. 
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initialization: generic term for first and re-initialization 

NOTE 1 : In both cases, the AT shall synchronize to the DL and then wait for a ranging invitation. 

• First Initialization: process which is required to bring the AT into the operational mode (i.e. the ability to 
establish connections) 

NOTE 2: The initialization shall be performed whenever a new AT enters the network. 

• Re-initialization: process that occurs when the AT is recovering from an out-of-service state or after a link 
loss or after a power supply interruption (PSI) 

NOTE 3: Re-initialization does not include the frequency scanning step and the AP can command if the capabilities 
negotiation steps and the authentication step shall be skipped or not. 

MAC PDU: data unit exchanged between the MAC sublayers of AP and AT, consisting of the MAC PDU header and 
the MAC PDU payload 

NOTE 1 : The MAC PDU header is different for DL and UL. 

NOTE 2: Several types of MAC PDUs have to be distinguished: 

MAC data PDU: created in the CL. 

■ Long MAC signalling PDU: created in the DLC layer with exactly the same format as a MAC 
data PDU and carries one or several MAC management messages. 

NOTE 3: By using SAR within the DLC layer, a MAC management message can be spread to several MAC PDUs, 
applicable both for DL and UL directions. 

• Short MAC signalling PDU: created in the DLC layer to carry one short MAC management messages. 
NOTE 4: This is restricted to the UL direction. 

• MAC dummy PDU: is created in the DLC layer for a purpose as follows: 

DL direction: to support continuous transmission in the DL. MAC dummy PDU can be inserted at any 
position in the DL frame, i.e. in any PHY mode region of the TDM or TDMA zones (to allow more 
flexibility of the AP scheduler, however, a location of the MAC dummy PDUs at the beginning of the 
TDM zone with the most robust PHY mode would improve synchronization). 

UL direction: to fill up the UL burst if grants are given but nothing is to be transmitted (e.g. if grants are 
given for ARQ-retransmissions but cannot be used completely in case of non-ARQ connections). 

map: generic term for the DL map, the UL map or the ARQ map: 

• DL map: part of the control zone that defines the Starting Symbols (SS) for the PHY mode regions inside the 
TDM or TDMA zones for the downlink. 

• UL map: part of the control zone that defines the SSs of the UL bursts. 

• ARQ map: part of the control zone that lists the SS of the erroneously received RS codewords (from the 
respective UL frame). 

mode: generic term for the duplex scheme: 

• FDD mode: Both AP and AT are transmitting and receiving data at the same time, the DL and UL RF carriers 
are separated by the duplex frequency, the two paired RF carriers form an RF channel. 

• TDD mode: DL and UL transmissions use the same RF carrier, both AP and AT are transmitting and 
receiving data not simultaneously, the RF channel is simply identical to one (unpaired) RF carrier. 

NOTE 1 : In case of two paired RF carriers, it is not excluded to operate two independent HA systems each in TDD 
mode in the two RF carriers. 

NOTE 2: The word "mode" is also used in the terms "PHY mode" and "initialization mode". 
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Offset (or Frame Offset, FO): The fixed time difference between DL frame and UL frame, selected by the AP. This 
applies only for the FDD mode 

NOTE 1 : FO should be at least 2/5 of the frame duration (i.e. the UL frame starts at least 0,40 ms after the DL 

frame) as an upper bound of the maximum length of the control zone, including also the maximum Round 
Trip Delay (RTD) and the processing time (TP) to allow for the decoding of the UL map in the AT before 
the first granted UL transmissions. 

NOTE 2: FO should be limited to the frame duration, i.e. in this case the DL and UL frames are exactly aligned. 

packet: data unit of variable length referenced by the packet-based CL 

PHY mode: combination of a signal constellation (modulation alphabet) and FEC parameters (coding scheme, i.e. inner 
and outer code, code rates, block lengths, etc) 

PHY mode Set Description (PSD): The PSD shall be carried in the GBI message. It contains a description of the 
C/(N + I) thresholds for one set of PHY modes. 

NOTE: Two specific PHY modes are selected for DL and UL (could be identical or different) on a 

frame-by-frame basis under control of the AP and communicated to the AT by messages (for DL) and 
UIUC (for UL). 

PHY mode region: part of the TDM (or TDMA) zone with fixed PHY mode, containing one or several FEC blocks 

NOTE: This applies only for the DL. 

preamble: specific sequence of channel symbols with a given auto-correlation property assisting modem 
synchronization and channel estimation 

Specific preambles are: 

• DL frame preamble: at the beginning of each DL frame, prior to the control zone, consisting of 32 symbols. 

• DL burst preamble: at the beginning of each DL PHY mode region in the optional TDMA zone, consisting 
of 16 symbols. 

• UL burst preamble: at the beginning of each UL burst, after the guard time, consisting of 16 or 32 symbols. 
The preamble length shall be commanded to the AT at initialization. Both lengths shall be supported by all 
ATs. 

ranging: process through which the AP compensates the individual delay of each AT up to the farthest distance 
allowed in the sector (i.e. the process that enables the AT to adjust its correct transmission time) and to define the 
correct AT transmit power setting 

NOTE: The ranging process can only be started with a ranging invitation and is identical for first and 

re-initialization: the AT transmits several times with increasing power in granted ranging bursts, 
terminated by a ranging response from the AP. 

RF block: group of one or several contiguous RF carriers 

NOTE 1: The FDD mode requires two separated RF blocks, one for the DL transmission (DL RF block) and one 
for the UL transmission (UL RF block). 

NOTE 2: The TDD mode can be accommodated in a single RF block or in several separated RF blocks. 

RF channel: pair of downlink and uplink carriers (in case of FDD mode) 

NOTE: For TDD mode, an RF channel is simply a carrier. For all modes, each carrier shall have a width of 
28 MHz. 



ETSI 



15 



ETSI TS 102 000 V1.3.1 (2002-12) 



RS codeword: result from the outer encoding of a number of information bytes 

NOTE: A RS codeword shall be subjected to a further inner encoding if applicable. A FEC block corresponds 
exactly to the combination of an RS codeword together with the trellis termination bits and the padding 
bits to complete a modulation symbol. The following cases can be distinguished: 

Long RS codewords (for MAC data PDU or long MAC signalling PDU in the DL): an RS 
codeword contains four MAC PDUs (or down to one MAC PDU by RS shortening if less MAC 
PDUs per PHY mode region are to be transmitted), i.e. (1 or 2 or 3 or 4) x (51 + 3 or 4) bytes are 
protected. 

■ Short RS codewords (for short MAC signalling PDU in the UL): An RS codeword protects one 
short MAC signalling PDU with a fixed length of 12 = 8 + 4 bytes. 

■ Short RS codewords (for the control zone in the DL): An RS codeword protects 30 bytes of the 
control zone. No RS shortening occurs since the length of the control zone shall be a multiple of 
30 bytes due to padding. 

sector: geographical area resulting from the splitting of a cell achieved by the use of the sector antenna 

NOTE: A sector can be covered by one or several antennas but all with the same azimuth and beamwidth. 

Depending on the implementation, one or several RF channels can be combined for a single antenna. 

Segmentation and Reassembly (SAR): segmentation of very long MAC management messages (created in the DLC 
layer) in the MAC sublayer 

NOTE: The length of a segment shall be 50 bytes, together with 1 additional byte for segmentation control (SCF). 

Segmented and non-segmented long MAC signalling PDUs are distinguished by the PT field in the MAC 
PDU header. SAR can be applied for DL and UL, but not for short MAC signalling PDUs and not in 
combination with packing. 

set of PHY modes: group of several PHY modes 

NOTE: Adaptive changes of PHY modes are only possible within the fixed set. Occasionally, a switch from one 
set of PHY mode to another set of PHY mode is possible. 

Starting Symbol (SS): numbering of modulation symbols in the DL frame used in the entries for all maps of the 
control zone: 

• DL map: the SS indicates the beginning of a PHY mode region, both for TDM and TDMA zones. The length 
of a PHY mode region shall be calculated from the difference of subsequent SSs. 

• ARQ map: the SS indicates the RS codeword (from the respective UL frame) where all MAC PDUs from this 
RS codeword for connections with ARQ shall be re-transmitted. 

• UL map: the SS indicates the beginning of a window or the beginning of a scheduled UL burst (with reference 
to the reception at the AP). Note that the SS does not include the AT-specific RTD and that each AT shall 
compute the real starting transmit time from the SS of the UL map and the RTD and the FO. 

subframe (or TDD subframe): part of the TDD frame, used either for DL or UL transmissions 

NOTE: The partitioning into DL and UL subframes can be adaptive (i.e. variable over time) or non-adaptive as 
well as synchronous (i.e. between APs of a network) or asynchronous. 

time: generic term for: 

• Starting time of UL bursts: Shall be computed from the Starting Symbol (SS) in the UL map and the Round 
Trip Delay (RTD) and the Frame Offset (FO). 

• Transmission Delay (TD): AT-specific delay for the transmission in DL or UL direction. 

• Round Trip Delay (RTD): equal to two times TD, depending on the specific AT. 

NOTE 1: The RTD and the TD are known and fixed at AP and AT after completion of the initialization process. 
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• Extended Guard Time (EGT): the maximum of the Round Trip Delay (RTD), depending on the sector 
radius. 

NOTE 2: The EGT shall be fixed and is not known outside of the AP. 

• Time for Processing (TP): time to decode the UL map from the control zone in the AT. 

NOTE 3: The TP shall not be broadcasted and only used in AP to select the appropriate Frame Offset (FO). Note 

that the fast decoding of the DL map shall be supported by the short RS codewords used for the protection 
of the control zone. 

• Frame Offset (FO): selected by the AP, could depend on the maximum length on the control zone under 
worst-case conditions and the Extended Guard Time (EGT). 

NOTE 4: The FO shall be fixed and broadcasted in the GBI message. 

Tx/Rx-Switching time: amount of time required to switch from reception to transmission or vice versa; in FDD mode 
used for H-FDD ATs; in TDD mode used for both AT and AP 

UpLink (UL): direction from AT to AP 

window (or bandwidth contention window): specific part of the UL frame which can be used in contention mode by 
all ATs for the bandwidth request message 

NOTE: The type and position of the window shall be broadcasted by one entry in the UL map. Note that the 

window is not always present in all frames. All UL transmissions in the window shall use the most robust 
PHY mode and always short MAC signalling PDUs. 

zone: generic term for a part of the DL frame (with continuous transmission, of variable length): 

• TDM zone: part of the DL frame consisting of different PHY mode regions, starting with the most robust 
PHY mode (decreasing order of PHY mode robustness). 

• TDMA zone: optional part of the DL frame consisting of different PHY mode regions, where each PHY mode 
region starts with a preamble used for synchronization of H-FDD ATs. A TDMA region may serve more than 
one AT by time division multiplexing DL data to several ATs. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

dBm decibel relative to 1 mW 

ppm parts per million 

3.3 Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ABR 


Available Bit Rate 


ACK 


ACKnowledge 


AES 


Advanced Encryption Standard 


AK 


Authentication Key 


AP 


Access Point (= base station) 


APC 


AP Controller 


APC-ID 


APC IDentity 


APT 


AP Transceiver 


AR 


Aggregate Request 


ARQ 


Automatic Repeat reQuest 


ASN.l 


Abstract Syntax Notation One 


AT 


Access Termination (= terminal subscriber station) 


ATM 


Asynchronous Transfer Mode 


ATPC 


Automatic Transmit Power Control 


ATTC 


Automatic Transmit Time Control 
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BCH 


Broadcast CHannel 


BER 


Bit Error Rate 


BFWA 


Broadband Fixed Wireless Access 


BR 


Bandwidth Request 


C/I 


Carrier-to-interference power ratio 


CA 


Connection Aggregate 


CAC 


Call Admission Control 


CAID 


Connection Aggregate IDentity 


CBR 


Constant Bit Rate 


CC 


Connection Control 


CDV 


Cell Delay Variation 


CI 


CRC Indicator 


CID 


Connection ID 


CL 


Convergence Layer 


CLID 


Convergence Layer IDentity 


CLP 


Cell Loss Priority 


CNF 


CoNFirm 


CNR 


Carrier-to-Noise power Ratio (also denoted by C/N) 


CPE 


Customer Premises Equipment 


CTD 


Cell Transfer Delay 


CW 


CodeWord 


DES 


Data Encryption Standard 


DHCP 


Dynamic Host Configuration Protocol 


DIUC 


Downlink Interval Usage Code 


DL 


DownLink 


DLC 


Data Link Control (layer) 


DOCSIS 


Data Over Cable Service Interface Specifications 


DVB 


Digital Video Broadcasting 


EC 


Error Control (refers to ARQ) 


ECN 


Encoding Control Notation 


EDE 


Encrypt-Decrypt-Encrypt 

J I J I J 1 


EGT 


Extended Guard Time 


EKS 


Encryption Key Sequence 


EMS 


Element Management System 


FDD 


Frequency Division Duplex 


FDMA 


Frequency Division Multiple Access 


FEC 


Forward Error Correction 


FO 


Frame Offset 


FSM 


Finite State Machines 


FSN 


Fragmentation Sequence Number 


FWA 


Fixed Wireless Access 


GBI 


General Broadcast Information 


GFC 


Generic Flow Control 


GFR 


Guaranteed Frame Rate 


GM 


Grant Management field 


GPT 


Grant Per Terminal 


H/2 


HIPERLAN Type 2 


HA 


HIPERACCESS 


HCS 


Header Check Sequence 


HEC 


Header Error Check 


H-FDD 


Half -duplex Frequency Division Duplex 


HIPER ACCESS 


High Performance Radio Access Network 


HIPERLAN 


High Performance Radio Local Area Network 


HIPERMAN 


High Performance Radio Metropolitan Access Network 


HL 


HIPERLAN 


HM 


HIPERMAN 


HMSC 


High-level MSC 


HT 


Header Type 


IC 


Initialization Control 


ID 


IDentity 


IDU 


InDoor Unit 


IETF 


Internet Engineering Task Force 



ETSI 



18 



ETSI TS 102 000 V1.3.1 (2002-12) 



IF 


Intermediate Frequency 


IMA 


Inverse Multiple Access 


IND 


INDication 


IP 


Internet Protocol 


ISDN 


Integrated Services Digital Network 


ISO 


International Standards Organization 


ITU 


International Telecommunications Union 


IUC 


Interval Usage Code (both for DL or UL) 


IV 


Initialization Vector (for encryption) 


IVP 


Indicator of Variable MAC PDU 


IWF 


InterWorking Function 


LAN 


Local Area Network 


LL 


Leased Line 


LLC 


Logical Link Control 


LoS 


Line of Sight (connection) 


MAC 


Medium Access Control 


MC 


Multicast 


MIB 


Management Information Base 


MPLS 


Multi Protocol Label Switching 


MSC 


Message Sequence Charts 


MT 


Message Type 


MTL 


Minimum Traffic Load 


NMS 


Network Management System 


NNI 


Network Node Interface 


nrt 


non-realtime 


NT 


Network Termination 


ODU 


OutDoor Unit 


OSI 


Open System Interconnect 


PABX 


Private Automatic Branch eXchange 


PB 


Piggyback Byte 


PDN 


Public Digital Network 


PDU 


Protocol Data Unit 


PER 


Packet Encoding Rule 


PHS 


Payload Header Suppression 


PHY 


PHYsical (layer) 


PKM 


Privacy Key Management 


PM 


Poll-Me bit 


PMP 


Point-to-MultiPoint 


POTS 


Plain Old Telephone Service 


PSD 


PHY mode Set Descriptor 


PSDI 


PHY mode Set Descriptor Indicator 


PSI 


Power Supply Interruption 


PSTN 


Public Switched Telephone Network 


PT 


PDU Type 


PTC 


Product Turbo Code 


PTD 


PDU Transfer Delay 


PTI 


Payload Type Indicator 


PVC 


Permanent Virtual Connection 


QAM 


Quadrature Amplitude Modulation 


QoS 


Quality of Service 


QPSK 


Quadrature Phase Shift Keying 


REQ 


REQuest 


RF 


Radio Frequency 


RGC 


Resource Grant Control 


RLC 


Radio Link Control 


RNC 


Radio Network Controller 


RRC 


Radio Resource Control 


RS 


Reed-Solomon (code) 


RSA 


Rivest Shamir Adleman (standard for asymmetric cryptography) 


RSB 


Request bit for Short UL Burst 


RSP 


ReSPonse 


RT 


Radio Termination 
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rt 


real-time 


RTD 


Round Trip Delay (equal to 2 times TD, AT-dependent) 


SA 


Security Association 


SAID 


Security Association IDentity 


SAP 


Service Access Point 


SAR 


Segmentation And Reassembly 


sc 


Security Control 


SCF 


Segmentation Control Field 


SCID 


Service Class IDentity 


SDL 


Specification and Description Language 


SDU 


Service Data Unit 


SI 


Slip Indicator 


SLA 


Service Level Agreement 


SME 


Small to Medium sized Enterprise 


SNI 


Service Node Interface 


SNMP 


Simple Network Management Protocol 


SNR 


Signal-to-Noise power Ratio (also denoted by S/N) 


SO 


System Overview 


SOHO 


Small Office/Home Office 


ss 


Starting Symbol 


STM 


Synchronous Transfer Mode 


SVC 


Switched Virtual Connection 


TC 


Transmission Convergence layer 


TD 


Transmission Delay (one direction, AT-dependent) 


TDD 


Time Division Duplex 


TDM 


Time Division Multiplex 


TDMA 


Time Division Multiple Access 


TEK 


Traffic Encryption Key 


TFTP 


Trivial File Transfer Protocol 


TID 


Terminal ID 


TP 


Time for Processing 


UBR 


Unspecified Bit Rate 


UIUC 


Uplink Interval Usage Code 


UL 


UpLink 


UMTS 


Universal Mobile Telecommunication System 


UNI 


User-Network Interface 


VBR 


Variable Bit Rate 


VBRnrt 


Variable Bit Rate non real time 


VBRrt 


Variable Bit Rate real time 


VC 


Virtual Connection 


VCI 


Virtual Connection Identity 


VoD 


Video on Demand 


VP 


Virtual Path 


VPI 


Virtual Path Identity 


VPN 


Virtual Private Network 


WWW 


World Wide Web 


xDSL 


x (= generic) Digital Subscriber Line 
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4 Overview 

This clause contains a short overview of the general HIPERACESS (HA) features, the network architecture and the 
interfaces as well as a summary of the main properties of the DLC layer and its relationship with other layers. 

4.1 Applications and services 

Potential applications of HA systems include, for example, residential customers, SMEs and UMTS backhaul service. 
HA will provide the support for a wide range of voice and broadband data services and facilities, including "bandwidth 
on demand" to deliver the appropriate data rate needed by the customer. For more details, see TR 102 003 [2]. 

The QoS of HA systems will behave, from the user perspective, like the QoS of wired broadband systems, such as 
xDSL and cable modems. The end users need not be aware that the services are delivered via radio. The performance in 
terms of BER, access delays, connection setup times and availability is to be comparable with the equivalent competing 
systems. QoS objectives are to be maintained even under adverse conditions of propagation, interference, equipment 
failure and increasing network load. 

HA systems are bearers for a wide diversity of applications. Not all applications need to be supported in all 
implementations of such systems. They may support a subset of the total set of possibilities, provided the services are 
supported in the specified manner. The data rate supported shall be variable on demand up to peak of tens of Mbit/s in 
UL plus DL directions delivered at the user network interface. It may be useful in some systems to allow only lower 
data rates to be supported, thereby decreasing the overall traffic requirement, which could reduce costs and lead to 
longer ranges. The average user rate varies for different applications. Generally, the peak data rate for a single user is 
required only for limited periods of time. The UL and DL user rates are usually not identical. 

4.2 Point-to-Multipoint (PMP) architecture 
4.2.1 General 

HA network deployments will potentially cover large areas like cities etc. Due to the large capacity requirements of the 
network, millimetre wave spectrum will be used, causing a limitation of the transmission ranges to a few kilometres. A 
typical network will therefore consist of some number of cells each covering a part of the designated deployment area. 




Figure 1 : Example of cellular configuration (4 x 90 sectors) 
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As shown in figure 1, a cell is partitioned into a small number of sectors by using sector azimuth patterned antennas at 
the AP, increasing spectrum efficiency by the possibility of re-using available RF channels in a systematic manner 
within the deployment area. Each sector is operated in a Point-to-Multipoint (PMP) manner, where an Access Point 
(AP) equipment device (also known as base station) located approximately at the cell centre, communicates with a 
number of Access Termination (AT) devices (also known as terminals or subscriber equipment) which are spread across 
the cell. 

It is emphasized that more than one subscriber within the sector may share an RF channel assigned to a specific sector, 
meaning that the ratio between AT equipment count and AP equipment count is typically a large number. As Line of 
Sight (LoS) conditions are essential for millimetre wave communications, cells may overlap in their coverage patterns. 
The overlap increases the likelihood of LoS conditions hence allowing for better market penetration. 

4.2.2 Interoperability aspects 

The HIPERACCESS standard will support interoperability at the air-interface, where interoperability means the ability 
of an AT designed and built according to the standards to intemperate with an AP designed and built independently to 
the same standards and to provide defined services according to an "inter-operation profile" specification. For 
interoperable systems, the following will be specified: 

• PHY layer, 

• DLC layer, 

• Interworking functions (to support UNIs and SNIs). 
Additional aspects to be specified for interoperable systems include: 

• Service management issues (for the control of allowed services, to generate traffic statistics, charging for use 
of network, etc.). 

• Network management issues (for the control of network resources, for the control of routing, to provide fault 
reporting, etc.). 

4.2.3 Duplex Schemes (FDD, TDD) and H-FDD operation 

As the communication channel between the AP and the ATs is bi-directional, the DL (downlink, direction from AP to 
AT) and UL (uplink, direction from AT to AP) paths shall be established utilizing the spectrum resource available to the 
operator. Two duplex schemes are specified, one is frequency-domain based (FDD) and one is time-domain based 
(TDD), used by two different operation modes of HA systems. Therefore FDD and TDD modes are optional for the AP; 
so one of the two modes shall be implemented. Each AT shall support the FDD mode (full or H-FDD) or the TDD 
mode. 

• For a Frequency Division Duplex (FDD) duplex scheme, the available spectrum is partitioned into a DL RF 
block and an UL RF block. An RF channel is actually a pair of carriers, one from the DL RF block and one for 
the UL RF block, hence DL and UL transmissions are established on separate and independent radio channels. 
In HIPERACCESS both DL and UL carriers are equal in size and fixed to a width of 28 MHz. 

• In the half -duplex FDD (H-FDD) operational mode, the AT radio equipment is limited to a half-duplex 
operation (i.e. transmission and reception cannot occur simultaneously), thus a relaxation of some RF design 
parameters is possible (e.g. isolation) and an AT cost reduction is facilitated. The DLC layer acknowledging 
AT limitations shall schedule the DL reception events and the UL transmission events accordingly. 
Furthermore the AP recognizes in this case the fact that switching from transmission operation to reception 
operation (and vice versa) at the AT is not immediately possible (i.e. a guard time for ramp up and down of the 
transmit power is required). 

• It is emphasized that the H-FDD operation is an AT feature only. The AP has a different impact on the 
deployment cost and on system capacity (if H-FDD operation is employed at the AP). Note that in addition to 
the AT burst transmission capability, the H-FDD operation requires burst reception capability as well. The 
H-FDD operation in the AT equipment is an optional feature. However the AP equipment shall support AT 
equipment which has implemented this feature. 
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• In contrast to FDD, the Time Division Duplex (TDD) duplex scheme shall use a single carrier of 28 MHz 
bandwidth for DL and UL communications. The AP establishes a frame based transmission as for FDD, but 
additionally the frame is divided into two parts: a subframe of the frame is allocated for DL purposes and the 
remainder of the frame for UL purposes. This time sharing ensures that DL and UL transmission events never 
overlap. The ratio between the allocated time for DL transmissions and the time allocated for UL 
transmissions is configurable. This ratio will be identical for a given deployment region in order to maximize 
capacity requirements by frame synchronization of all cells. 

Note that in general the TDD standard is based completely on the FDD standard. This means that the TDD operation 
shall use identical parameters to those of FDD, which is straightforward as the FDD operation consists of fixed length 
framed transmissions. In other words, FDD is the main application of HIPERACCESS systems and no specific opposed 
or additional optimizations for TDD are envisaged. 

4.2.4 Multiplexing techniques and frame structure 

As more than one AT is sharing the same UL carrier, the AP shall employ techniques controlling the access of ATs. 
Only TDMA (Time Division Multiple Access) shall be used. After an AT has been initialized with the system, its UL 
transmission events are scheduled by the AP. Scheduled events are basically time coordinates which uniquely define 
when the AT shall begin and end its transmission. The schedule data for UL transmission is organized in an UL map 
which is broadcasted in the DL. An AT can transmit in a contention based manner only for bandwidth requests. 

The DL data stream to different ATs is multiplexed in the time domain (TDM). As HA systems employ adaptive PHY 
modes, a frame consists of a few TDM regions. Each TDM region is assigned with a specific PHY mode. Only ATs 
capable of receiving (i.e. successfully demodulating and decoding) the assigned PHY mode may find their DL data 
multiplexed in the associated TDM region. For simplifying the demodulation process, TDM regions are allocated in a 
robustness descending order. For example, an AT with excellent link conditions, which is assigned to a spectrum 
efficient PHY mode, starts its reception process at the beginning of the frame and continues through all TDM regions 
(using a more robust PHY mode) ending its reception process with its associated TDM region. An AT with worse link 
conditions will be assigned to a more robust PHY mode and its reception process will end before the AT of the previous 
example. Note that in any case all synchronization related operation is performed once per frame for all ATs. 

The TDM region location within a frame is broadcasted at the beginning of a DL frame in the DL map, together with 
the UL map, used instead to give grants to different ATs. Both DL and UL maps together with the ARQ map and some 
other information fields are referred to as the control zone at the beginning of the frame. 

TDMA transmissions could be optionally present in a TDMA zone on the DL in addition to the DL TDM zone. In this 
scheme, an H-FDD AT may be assigned to receive DL transmissions either in a TDM region as previously discussed or 
in a TDMA region. The TDMA region allocations are broadcasted as part of the DL map. With no DL TDMA zone, a 
half -duplex AT has limited opportunities to transmit as it is forced to demodulate the DL continuously from the 
beginning of the DL frame and once it transmits it shall wait for the next DL frame to re-synchronize. With the DL 
TDMA option the AT may seek DL reception opportunities immediately after it ceased its UL transmission within the 
current DL frame. The AP scheduling procedures should use the DL TDMA feature as it increases channel utilization 
and minimizes latencies. Note that a TDMA region may serve more than one AT by time division multiplexing DL data 
of several ATs. 

4.3 Basic Arrangement of HA networks 
4.3.1 System and reference configuration 

The HA radio access system can be deployed to connect user-network interfaces (UNI, also referred to as W.3) located 
in and physically fixed to the customer premises equipment (CPE) to a service node interface (SNI, also referred to as 
W.2) of a broadband core network (e.g. IP, ATM, LL). 

As it is illustrated in figure 2, the AP typically manages the communication of more than one sector. If there is more 
than one sector per geographical cell or more than one RF channel per sector, the AP can be split into an APC and 
several APTs as shown in figure 2. Each APT serves only one RF channel, but a single APC can serve all RF channels 
and all sectors of a geographical cell. An AT can be switched from one to another RF channel under control of the APC 
(addressed as load-levelling or inter-carrier handover). An AT can not be switched from one to another sector. 
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Figure 2: Configuration model for HA systems 

For each sector one antenna (or maybe more) is positioned to cover the deployment region. A feeding structure connects 
all APTs serving one sector with the antenna(s). In other words, several carriers are using the same antenna, but 
different sectors require different antennas. 

The AT antenna is highly directional, pointed to the serving AP. A feeding structure connects the radio transceiver with 
the antenna. At the AT side, the Network Termination (NT) interface connects the AT with the local user network 
interface (UNI). 

The AT and the AP are connected via the air-interface (also referred to as W.l), where its DLC layer specification will 
be described in the present document. The communication channel between the AP and the ATs is bi-directional, the 
DL (from AP to AT) and the UL (from AT to AP) paths shall be established utilizing the spectrum resource available to 
the operator. 

The internal interface between APT and APC is not considered in the present document. 
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4.3.2 External and internal interfaces, interworking functions 

The detailed HA reference model illustrated in figure 3 provides an overview of the interworking functions as well as 
the internal and external interfaces. 
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Figure 3: Reference model and interfaces for HA systems 

InterWorking Functions (IWF) occur at two points to translate the internal HA interfaces to external interfaces: 

• One type of IWF is required to translate the internal interface B.2 into network-specific interfaces of the 
particular core network (such as ATM or IP). 

• The other type of IWF is required to translate the internal interface B.l into external interfaces with the 
terminal equipment. 

IWFs are logical entities and no particular physical location is implied by their position in the HA configuration 
diagram. The interfaces B.l and B.2 are internal service interfaces, which are specified at logical level only, the 
implementations may vary. 

The external interfaces between network elements (i.e. access termination and access point) are the following: 

• Interface between AT and AP (air-interface, W.l): fully specified by the HA PHY and DLC TS documents. 

• Interface between AP and core networks (W.2, identical to SNI): specified by other bodies, the list of 
supported interfaces and related IWF definition shall be specified within the CL. 

• Interface between AT and terminal equipment or user application (W.3, identical to UNI): specified by 
other bodies, the list of supported interfaces and related IWF definition shall be specified within the CL. 

• Interface between AP and element management system (B.3): use of an available open standard protocol. 
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4.3.3 Layer architecture and functional entities 

The HA protocol stack consists of the unique PHY layer on the bottom, the unique DLC layer in the middle and one or 
more convergence layers (CL, also addressed as IWF) on top as shown in figure 4. The interfaces between layers are as 
follows: 

• Interface between DLC and PHY layer: a normative and testable interface between these two layers is not 
specified, but an informative description is provided both in the DLC and PHY TSs. 

• The DLC layer is responsible for the construction of entire PDUs, so the PHY layer shall handle only entire 
MAC PDUs and different fields within a MAC PDU are not visible for, and are not interpreted by the PHY 
layer. 

• Interfaces within DLC: sublayers within the DLC layer are not formally specified, so there are no normative 
and testable interfaces within the DLC layer. 

• Interface between DLC and CL (SAP): is described informally in detail in the present document. 
The scope of the HA standard ends at the upper end of the CL. On top of the CL further higher layers are located. 



Higher Layers 
CL SAPs 



Convergence Layer 
DLC Control SAP DLC User SAP 



RLC sublayer 




Radio Link Control 
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layer 



MAC sublayer 
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Figure 4: Protocol layer structure (for AP) 
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The difference of the protocol stack between AP and AT is that the AT contains only one RLC and MAC entity, 
whereas the AP contains one RLC entity per AT. The RLC sublayer shall contain: 

• radio resource control (including load levelling, power levelling and change of PHY modes), 

• initialization control (first initialization and re-initialization of ATs), 

• connection control (on DLC level), and 

• security control (encryption for privacy, authentication of ATs). 

Service primitives to the CL only exist for connection control, since radio resource control and initialization control are 
related to the AT in total and not to particular connections and security control shall be completely invisible for the CL. 

The present document is confined to the definition of the highlighted part shaded in grey. Hence, it describes mainly the 
DLC basic data transport functions, the messages to be transmitted over the air-interface including their formats for 
RLC and MAC (including ARQ functions) as well as the SAP to the CL. 

The MAC protocol is based on TDM/TDMA access scheme(s) with centralized control and either FDD or TDD mode 
support. The allocation of resources is fully controlled by the AP. It is assumed that one MAC entity with one instance 
is provided per AP as well as per AT. The algorithms for MAC and schedulers are out of the scope of the present 
document. 

In order to control the allocation of resources, the AP needs to know the state of its own buffers and of the buffers in all 
ATs. Therefore, the ATs report their buffer states in resource request messages to the AP. Using this mechanism, the 
ATs request for resources in terms of transmission capacity. Moreover, an optional feature is to negotiate a fixed 
capacity allocation over multiple frames. The AP allocates the resources according to the buffer states on a fair basis 
and, if required, taking QoS parameters into account. The allocation of resources is conveyed by resource grant 
messages. Requests are defined on a per connection or per connection aggregate basis, whereas grants are given on a 
per AT basis. 

The MAC sublayer includes also an instance for EC (Error Control) which is responsible for detection and recovery 
from transmission errors on the radio link. An ARQ (Automatic Repeat Request) protocol can be applied on a per 
connection basis. Most ARQ functions (like the mechanisms for requests and grants of re-transmissions) are indeed 
DLC related, however, the error detection itself is performed in the PHY layer. ARQ also ensures the in-sequence 
delivery of MAC PDUs. A dedicated ARQ instance can be assigned to each DLC connection for non-real time data 
services and maybe even for real time CBR services if the delay requirements are less strict. ARQ is negotiated at 
connection establishment. In particular ARQ shall not be applied to any RLC signalling. ARQ is only applied to the UL 
direction. The support and implementation of ARQ is optional for the AP but mandatory for all ATs. 

NOTE: Architectures where the AP is split into an AP controller and one or more AP transceivers are not 

precluded by the present document. If the split between AP controller and AP transceiver is below the 
DLC layer, more than one MAC entity may exist in the AP controller. 

4.4 Convergence Layers 

The function of the Convergence Layer (CL) is the Interworking Function (IWF) for mapping services over the DLC 
frame, specified for different services at the AT side and different core networks at the AP side. There are at least two 
convergence layers, a cell-based CL for ATM and a packet-based CL for IP. 

The RLC sublayer receives from the CL a QoS description for each connection. The grouping of connections into 
connection aggregates is performed in the DLC layer. 

The identifier of the Convergence Layer is called Clid and it is transported in a lot of messages. The format of the Clid 
is described in table 1 . 



Table 1 : Clid format 



Clid : 


:= INTEGER 






{ cellBased 


(1) , 




packetBased 


(2) } (0. .7) 
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4.4.1 Cell-based Convergence Layer 

The cell-based CL (Convergence Layer) is dedicated to interface the ATM layer to the HA DLC layer. At ATM level 
several classes of service are defined together with the requirements on QoS they are able to respect. The DLC level 
shall be able to be compliant with the QoS requirements coming from at least the following ATM class of service: 

• Constant Bit Rate (CBR) 

• Variable Bit Rate real time (VBRrt) 

• Variable Bit Rate non real time (VBRnrt) 

• Unspecified Bit Rate (UBR) 

To ensure the support of these service classes four different service categories have been defined within the DLC layer 
(see clause 4.4.3). 

For the handling of data cells coming from the ATM layer (see clause 5.2.1). 

4.4.2 Packet-based Convergence Layer 

The packet-based CL (Convergence Layer) is dedicated to interface any packet oriented upper layer to the HA DLC 
layer. At CL a Segmentation and Reassembly (SAR) functionality shall be provided in order to exchange with the DLC 
level fixed packet data units. 

NOTE: Another different SAR entity within the MAC sublayer is defined to segment long MAC management 
messages. 

Quality and priority classes (as needed for different QoS levels) shall be supported. This is accomplished by mapping 
the quality and priority classes of the specific packet-based CL to the service categories defined within the DLC layer 
(see clause 4.4.3). 

Requirements to specify the support of e.g. differentiated services are mainly an issue of the CL and not of the DLC 
layer. 

The way the segmentation (and reassembly) shall be performed (i.e. the payload length and header attachment) is 
specified in clause 5.2.2. 

4.4.3 Handling of DLC QoS classes 

The HA system is supposed to support applications like business access, residential access, 2G and 3G backhaul traffic 
transport etc. These services have different characteristics and as a consequence different timing limitations. At the 
DLC level four service categories have been defined: 

• Periodic Real Time 

Periodic bandwidth guaranteed; tight constraints on both delay and delay variation. This class is intended 
for support of e.g. ATM CBR services. 

• Real Time 

Minimum bandwidth guaranteed; tight constraints on both delay and delay variation. 

• Non Real Time 

Minimum bandwidth guaranteed; no constraints on delay and delay variation. 

• Best Effort 

No bandwidth guaranteed; no constraints on delay and delay variation. 
Once the service classes for the DLC level have been stated, they define the service offered to the upper layers. 
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Upper level service categories can require strict time constraints defining a bound for delay parameters (i.e. in the ATM 
case the CTD or CDV parameters). To allow the CL to fulfil the delay requirements according to the needs of the 
supported service classes, an upper limit on the MAC PDU transfer delay shall be introduced. This value shall refer to 
the path from the transmitting to the receiving end specifying the total guaranteed traffic load during the measure. 

This limit means the maximum delay that a MAC data PDU belonging to a connection of the highest service category 
may experience since entering the DLC at the transmitting side until it is passed to the upper layer at the receiving side. 

The whole MAC PDU delay constraint, represented by maximum MAC PDU transfer delay, introduced by the path 
from the transmitting to the receiving side allows to state a limit on the delay that the DLC introduces for the highest 
priority DLC service category. Every MAC PDU belonging to the Real Time service will experience a delay smaller 
than the maximum transfer delay. Instead, for the excess traffic it is not possible to define a time constraint, since the 
delay is a function of the system congestion. 

Since the PTD is a function of the guaranteed traffic load, a practical way to define a measure is to state the guaranteed 
traffic load condition when the maximum PTD is reached or maximum PTD at 100 % of guaranteed traffic load, if the 
PTD is lower then the limit. 

Table 2 is normative. It shows the performance the HIPERACCESS system shall be able to meet. More relaxed values 
can be set for individual connections. 



Table 2: DLC Service Category Limitation (transmitter side) 



Service category 


Priority 


Max PDU Delay 


Max PDU transfer 


Bit rate 






variation 


delay 




Periodic Real Time 





5 ms 


5 ms 


Periodic guaranteed 


Real Time 


1 


5 ms 


5 ms 


Min guaranteed 


Non Real Time 


2 


NA 


NA 


Min guaranteed 


Best Effort 


3 


NA 


NA 


No guarantees 



The delay variation reported in the table refers to the maximum peak-to-peak delay variation (PDVpeak-to-peak) that is 
given by the difference PTDmax - PTDmin, where PTDmin is the minimum delay experienced by a PDU in the transit 
through the DLC layer. If PTDmin is negligible respect to the PDTmax, the PDVpeak-to-peak and the PTDmax have 
the same value. In the table above the reported delay variation is the maximum reachable value, supposing the 
PTDmin = 0. In case the ARQ is used the PTDmin is 3 ms at least. If PTDmin is not zero, the sum of the delay variation 
and the PTDmin shall be within the PTDmax. The maximum transfer delay for any single PDU shall not be larger than 
PTDmax. 

It should be noticed that the DLC functionality, is distributed between two separated entities: for the DL the AP is the 
only entity involved in traffic handling, while for UL traffic decisions are taken both in AP and AT. 

The AP in DL and both the AP and the AT in UL are congestion points and, due to the statistical multiplexing of traffic, 
they introduce a delay variation. 

In the downlink direction the values of the system parameters on delay are referred to the AP only, whereas in the 
uplink direction, being the AT a congestion point for the incoming traffic from the line and the AP a congestion point 
related to the handling of the bandwidth requested by the ATs, two contributions can be defined: 

• Uplink AT PTD: maximum delay introduced by the statistical multiplexing at AT level when a continuous 
flow of transmission grants is received from the AP. 

• Uplink AP PTD: maximum delay introduced by the statistical multiplexing at AP level supposing the ATs has 
continuously PDUs to be transmitted. 

The downlink PTD and the sum of the uplink PTDs have to be within the maximum PTD defined as system parameter, 
supposing the ARQ is not used. When the ARQ is adopted, the PTD that it introduces has to be added to the uplink AT 
and AP PTDs and the total value shall be within the maxPTD defined as system parameter. 

Since the PTD is a function of the guaranteed traffic load, a practical way to define a measure is to state the guaranteed 
traffic load condition when the maximum PTD is reached or the maximum PTD at 100 % of guaranteed traffic load, if 
the PTD is lower than the limit. 
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4.5 Data Link Control (DLC) Layer 

4.5.1 Overview and basic features 

The DLC layer is connection oriented (this means that MAC PDUs are received in the same order as sent and that a 
connection is set up before MAC PDUs are sent) to guarantee QoS. Connections are set up over the air during the 
initialization of an AT, and additionally new connections may be established when new services are required. 

Both ATM and IP are supported efficiently by means of a fixed MAC PDU size of 51 bytes: 

• The efficient support of ATM is achieved by a one-to-one correspondence between the ATM cells of 51 bytes 
(full ATM cell except HEC and VPI fields) and the MAC PDU. All mechanisms for: 

request-grant, 

ARQ (optional for AP), 

error-detection and performance monitoring, 

are oriented towards MAC PDUs and thus towards ATM cells in case of cell-based CL. The solution with the 
shortened ATM header (of 3 bytes) offers also the unconditional support of VP switching. 

• For the efficient support of IP, the variable length IP packets are mapped by S AR to the fixed size MAC 
PDUs. 

It should be noted for cell-based CL that other solutions like selectable MAC PDU size, segmentation of ATM cells in 
the CL to 48 bytes or hand-shaking procedures for a (VPI,VCI) mapping to CID during connection establishments do 
not offer any advantages. 

ARQ is not specified for the DL direction but it shall be supported by the DLC and PHY layer for the UL direction 
where the AP shall switch on/off ARQ on a per connection basis. 

A short description of the main functional entities of the DLC and PHY layers follows. 

4.5.2 Radio Link Control (RLC) sublayer 

The RLC sublayer contains radio resource control in particular, initialization control, connection control (on a DLC 
level) and security control. 

• Radio resource control: This includes all mechanisms for load levelling, power levelling (UL ATPC and DL 
ATPC) and change of PHY modes. These functions are radio link-specific and thus AT-specific except for the 
carrier-specific DL ATPC. 

• Initialization control: This includes all mechanisms for the initial access (first initialization) and release of a 
terminal to/from the network as well as the re-initialization process required in case of link interruptions or 
PSI. These functions are AT-specific. 

• DLC connection control: This includes all mechanisms for connection establishment, connection change and 
connection release; the association of a specific connection to a specific Connection Aggregate IDentity 
(CAID), Security Aggregate IDentity (SAID) and a specific Service Category IDentity (SCID). The 
configuration of QoS parameters for a certain connection is also part of connection control. All these functions 
are of course connection-specific. The following table gives the correspondence between SCID values and the 
QoS classes: 



SCID value 


QoS Class 





PRT j 


1 


RT 


2 


nRT 


3 


BE 



Security control: This includes all mechanisms for authentication of ATs and the connection-specific 
encryption control. These functions are both terminal - and connection - specific. 
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4.5.3 Medium Access Control (MAC) sublayer 

Some important key features are: 

• Requests are per connection or per connection aggregate. 

• Grants are given per terminal. 

• Connections are grouped into connection aggregates. 

• Several request-grant mechanisms are supported. 

• ARQ is optionally supported in the AP. 

4.5.4 Error control (ARQ) within the MAC sublayer 

The adaptive operation of modulation and coding is able to counteract the slow propagation behaviour in case of rain 
fading but is powerless against the fast behaviour of the uplink interference. 

Indeed while the C/I (carrier-to-interference power ratio) in the DL can be deterministically evaluated and effectively 
counteracted by FEC mechanism at the PHY layer, the interference in the UL direction is time-variant, as it depends on 
the location and the number of the simultaneous interfering ATs from other cells or sectors. The time-variant C/I 
behaviour in the UL can cause unacceptable service unavailability when exceeding the FEC capability. The higher the 
"PHY mode" throughput, the higher is the related unavailable time. Therefore the UL PHY modes with higher code 
rates or higher-level modulation schemes are more effectively usable if particular mechanism like ARQ are applicable. 

The ARQ protocol shall be implemented at the DLC level, where the error detection is performed in the PHY layer. It is 
based on a selective-repeat approach as described in clause 8.5, where only the PDUs carried by erroneously received 
RS codewords are to be re-transmitted. In the AP, the received RS codewords are checked and in case of detected errors 
the RS codeword itself and all PDUs carried by this codeword are discarded. If one erroneous RS codeword in an UL 
frame is detected, then the AP will set an indication in the control zone of the next DL frame, enforcing a 
re-transmission procedure for all PDUs belonging to all erroneous RS codewords of those ATs which have at least one 
connection with ARQ. The impact of ARQ in terms of delay and spectrum efficiency is described in clause 8.5.5. 

4.5.5 Security control within the RLC sublayer 

The most important security requirements are as follows: 

• Protection of traffic privacy. 

• Fraud prevention. 

• Checks for legitimate use. 

• A "medium" security level seems enough since high-security applications will use their own end-to-end 
security mechanisms. As a consequence, a protection against active attacks (e.g. message integrity protection) 
is not provided. Furthermore, a legal interception from the air-interface is not supported, since this should be 
supported by the network or in higher layers. 

The key mechanisms and protocols for security control are as follows: 

• Authentication of ATs based on X.509 [9] certificates. 

• Three-level cryptographic scheme: 

asymmetric RSA, used for authentication and AK transmission; 

symmetric AK (Authentication Key), encrypted with RSA for transmission, used for TEK transmission; 

symmetric TEK (Traffic Encryption Key), encrypted with AK for transmission, used for the encryption 
of the payload part of all unicast traffic connections (all management connections and all broadcast and 
multicast connections shall not be encrypted). 

• Frequent changes of keys are possible during traffic transmission. Lifetime for AK and TEK. 
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• Security functions (authentication and encryption) can be switched off (to allow the operation of HA systems 
in countries where encryption is legally not allowed). 

4.5.6 Multicast connections 

A multicast connection is defined as follows: 

The same stream of information is addressed to a group of connections (belonging to the same or different terminals), 
which is referred to as a multicast group. To save bandwidth, the information is transmitted only once over the air, 
whereas the transmission at the SNI could be once per connection or once per multicast group. Multicast transmissions 
exist only in the DL. Several multicast groups comprising different sets of connections can exist in parallel. All 
multicast groups are dynamic, i.e. connections can be allocated to a group or withdrawn from a group at any time. 

Multicast connections shall be supported. Encryption for multicast on the PHY and DLC layer is not supported in the 
standard but not excluded for future versions of HA. 

4.6 Physical (PHY) layer 

A short description of the PHY layer is included here for a comprehensive understanding, since the following key 
features of the PHY layer have to be supported by the DLC layer: 

• Adaptive PHY mode (coding and modulation) for DL and UL. 

• Transmit power control (ATPC) for DL (optional) and UL. 
Some more details are given in clauses 4.6.1 and 4.6.2. 

4.6.1 Adaptive coding and modulation 

Typically when a carrier is shared by more than one AT, modulation and coding parameters are set according to the AT 
which has the greatest path loss or is exposed to the greatest amount of interference. Coupled with the fact that the 
operator wishes to maximize the coverage, the modulation and coding scheme in these cases shall be robust yet 
spectrum inefficient (i.e. QPSK with a low code rate). 

Even if the cell size is greatly reduced, potentially allowing for higher order modulation schemes (i.e. 64QAM) to be 
used, the self -interference conditions (due to the multi-cell deployment) will dominate and prevent service to some large 
number of ATs (i.e. coverage dead spots). 

HA uses adaptive PHY modes for solving this problem. A PHY mode is a predefined combination of modulation and 
coding parameters. In contrast with other transmission systems where one PHY mode dominated the entire DL 
transmission, for HA more than one PHY mode is used occupying different parts of the DL frame. In the UL different 
ATs use different PHY modes according to their individual link conditions. 

The AP controls the use of a specific PHY mode. If for example link conditions deteriorate (i.e. rain) then it is expected 
that more ATs will be assigned to more robust PHY modes. If the link recovers then it is expected that more ATs will 
be assigned to more spectrum efficient PHY modes within their link limitations. Although in some deployment 
scenarios UL transmissions can employ similar techniques to those of the DL, there will be some cases where it will be 
useful to limit the choices of PHY modes for the UL due to a different, random-like, interference behaviour especially 
apparent when the available spectrum is re-used aggressively. 

All modulation formats are M-QAM based. The forward error correction scheme will be based on an RS code 
concatenated with a convolutional code with no interleaving. 
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In order to guarantee the interoperability, the following rules shall be applied: 

• The indication of the PHY mode shall be done on a burst-by-burst basis. 

• Each AT shall measure the C/(N + I) ratio and the received power and communicate these values to the AP. 
Then, following these parameters, AP centrally decides to change the DL PHY mode or not. 

• For the UL a minimum amount of traffic shall be ensured in order for the AP to be able to continuously 
measure the C/(N + I) ratio with a given accuracy. 

• HA shall use one mandatory and one optional predefined set of PHY modes. The first set of PHY modes shall 
be supported by the AT and AP; where the second set shall be mandatory for AT and optional for AP. 

• Out of these sets of PHY modes, only one set of PHY modes shall be used per sector. The choice of the set of 
PHY modes could be determined by the network management system. A change of the PHY mode set should 
be synchronized between all RF channels of a sector. 

4.6.2 Automatic Transmit Power Control (ATPC) 

The transmit power control is needed in order to cope with attenuation effects due to rain fading. Both UL ATPC and 
DL ATPC are under full control of the AP. 

For the UL ATPC, each AT receives individual power adjustment commands from the AP. Usually, the UL transmit 
power is only changed in case of a rain fading. The AP gains the information about each AT's reasonable transmit 
power from the measurement of the received UL signal as well as from the parameters in the measurement reports from 
the ATs (where the present document contains the current transmit power and the current power margin among other 
parameters). As for the adaptive UL PHY mode, the AP gives enough grants to all ATs (even if the AT has no traffic to 
transmit) to measure the received UL power with the required precision. 

In order to guarantee the interoperability, the following rules shall be applied for UL ATPC: 

• The change of the transmit power shall be done on a frame-by-frame basis (both for DL and UL). 

• Each AT shall report the current transmit power to the AP. Then, following these parameters and own 
measurements of the received UL signal, the AP decides to command an UL power adjustment. 

• For the UL a minimum amount of traffic shall be ensured in order for the AP to be able to continuously 
measure the received UL power with a given accuracy. 

In case of initial ranging, the AT shall start the transmission of the UL ranging bursts with an estimation of the proper 
power level. Then the power shall be increased with a pre-defined step size until the UL ranging burst is received by the 
AP for the first time and the AP replies with a power adjustment message. Only in case of short link interruptions, the 
AP can allow the AT to resume its UL transmission with the old UL transmit power setting. 

The DL ATPC is an optional feature to fulfil regulatory requirements (where applicable). The DL transmit power can be 
changed for all carriers of a sector without notifying the ATs in advance. The DL transmit power shall be increased only 
if the current DL transmit power is not high enough for at least one AT in the most robust mode. In other words, the DL 
transmit power shall be minimized to allow the reception of the most robust PHY mode even for the AT with the worst 
DL radio channel conditions, but shall not be maximized to allow the use of the most efficient PHY mode for a large 
number of ATs. 



The interface between the DLC layer and the PHY layer is only informative. 

Further interfaces within the DLC layer are not specified, i.e. the MAC and RLC sublayers of the DLC layer are 
introduced to improve the readability of the present document and are of informative character only. 
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5.1 Definition of MAC PDU 

5.1 .1 Layer overview and general definitions (CL PDU and MAC PDU) 

Protocol Data Units (PDU) and Service Data Units (SDU) are only defined with respect to a specific layer. In the 
downward direction, the SDU is the input from an upper layer to a lower layer and the PDU is exchanged between the 
respective layers of transmitting and receiving entity. 

To reduce the number of names and definitions, the term SDU is not widely used in the present document. For the 
purpose of the DLC specification, only the CL SDU and the MAC PDU are of major importance. Two overviews are 
provided: in figure 5 with regards to the protocol stack and in figure 6 with regards to the structure of the data fields. 
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Figure 5: SDU and PDU in the protocol stack 

As shown in figure 5, the DLC SDUs received from the CL have a fixed length of 51 bytes, regardless of a cell-based 
CL (the HEC and VPI fields of an ATM cell are suppressed in the CL) or a packet-based CL (long IP packets are 
segmented within the CL). 

In the DLC layer, a DLC SDU is addressed as MAC data PDU payload and extended by the MAC PDU header to form 
the MAC PDU. The format of a MAC data PDU and a long MAC signalling PDU are identical. Additionally, there are 
also short MAC signalling PDUs for the UL direction. Both long and short MAC signalling PDUs carry messages that 
are created in the DLC layer. If these messages are too long then they are segmented to 5 1 bytes (including FC 
information) within the DLC layer. 
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5.1.2 Long MAC PDUs 

Figure 6 provides a more detailed overview of the structure of a MAC data PDU and a long MAC signalling PDU, 
where the numbers specify the length in bytes. The length of a MAC PDU payload is always fixed to 51 bytes except 
for short MAC signalling PDUs. 



MAC PDU 



4forUL 
3 for DL 



51 



^ 

MAC PDU ! 
header l 
I 



MAC PDU payload 



48 



or packet of several messages 
or segment of one long message 



Y 

CL header 


CL payload 













51 






one message 



general 



e.g. for 
cell-based CL 



for MAC management 
messages 

(long MAC signaling PDU) 



Figure 6: Structure of MAC data PDU and long MAC signalling PDU 

The MAC PDUs are created in the DLC layer. The MAC PDU payload is either received from the CL (consisting of CL 
header and CL payload) or generated as MAC management message in the DLC layer. Only the MAC PDU header has 
a format depending on the direction of the transmission. 

PDUs received from the CL are distinguished from PDUs created in the DLC layer (like MAC management messages 
or broadcast messages) by the CID field in the MAC PDU header, and additionally MAC data PDUs are distinguished 
from MAC signalling PDUs by the PT field in the header. 

A long MAC signalling PDU can carry one or several MAC management message(s) or a segment as shown in figure 6 
(see clause 7.4 for the lists of message format). 

MAC data PDUs shall be used to carry data only. Only the payload part of a unicast MAC data PDU is encrypted in the 
DLC layer to guarantee for privacy, whereas MAC signalling PDUs or multicast MAC data PDUs are not encrypted. 
The MAC PDU header is not encrypted. 
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5.1.3 Short MAC PDU 

Figure 7 shows the definition of the short MAC signalling PDU used only for UL which is created in the DLC layer. 
The payload length is 8 bytes (including the MT field) to accommodate the ranging request message. 



Short MAC signaling PDU 



MAC PDU 
header 



one message 



Figure 7: Structure of short MAC signalling PDU (UL only) 



5.2 Interface DLC-PHY 

The interface between DLC and PHY layer is not formally specified, so this clause is only informative. As long as the 
interoperability is guaranteed, the exact implementation of this interface is a manufacturer design. 

Clause 5.2.1 provides a description of the informative interface by block diagrams and parameter lists. Clause 5.2.2 
shows an overview of the data units in the transmitter and receiver chains and the following clauses give a description 
of how MAC PDUs are converted to PHY SDUs and are transmitted over the PHY layer and the air-interface, 
especially their allocation to FEC blocks. Their interrelation with maps and zones is covered in detail in clause 8. 



5.2.1 Informal description in terms of detailed parameter lists 

A normative and testable interface between these two layers is not specified, but an informative description is provided. 
The DLC layer is responsible for the construction of entire PDUs, so the PHY layer shall handle only entire PHY SDUs 
and the different fields within a PHY SDU are not visible for, and are not interpreted by, the PHY layer. 
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Figure 8: Block-diagram of the DLC-PHY interface 
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Figure 8 shows the block-diagram of this interface in AP and in AT. 

All messaging between the PHY and DLC layers in AP and AT and for transmitter and receiver sides are listed in 
table 3 to table 6. 

Table 3: Interface between DLC and PHY in AP (transmitter side) 



Signals/Messages 
Transmission Side 


Detailed parameters 


Timing 


Start of a frame and Start time of TDM or TDMA PHY mode regions 


PDU-Type 


Transmit Long MAC PDUs of 54 bytes or control zone bytes 


TX MAC PDUs/Control 
zone bytes 


MAC PDUs bytes or control zone bytes to be transmitted per TDM/TDMA Phy 
mode region 


TX-PHY-Mode 


PHY mode for each TDM or TDMA region 


Power control 


Relative power control signal 


TX-Carrier Freq. Select 


Selection of the TX carrier frequency, load levelling 


Alarm 


Alarm from DLC for stropping the transmission in the PHY 


Table 4: Interface between DLC and PHY in AP (receiver side) 



Signals/Messages 
Reception Side 


Detailed parameters 


Timing 


Time to start to detect a burst 


Burst-Type 


Long burst of n x 55 MAC-PDUs-bytes or short signalling burst carrying 12 bytes 


Preamble type 


16 or 32 symbols 


Burst concatenation 


Burst concatenation: Yes or not 


RX-PHY-Mode 


PHY mode for each UL-burst 


RX-Carrier Freq. Select 


Selection of the Rx carrier frequency, load levelling 


RX-MAC-PDUs 


Received n x 55 long MAC-PDUs bytes or short signalling MAC-PDU bytes 


RS-error flag 


Error flag per each RS decoded block 


Burst acquisition Akn. 


Acknowledgment for a successful acquisition of a burst 


CNR, RX-Power 


Measured CNR and RX-power 


Perf. Monitoring 


Information collected by the PHY-layer about link quality following ITU-T 
Recommendations G.821 [3]/G.826 [4]/M.2100 [6]. 


Alarm, LOS 


Alarm for anomaly from RX-PHY to DLC or Los of synchronization signalling 



Table 5: Interface between DLC and PHY in AT (transmitter side) 



Signals/Messages 
Transmission Side 


Detailed parameters 




Timing 


Start time for the transmission of a burst 


Burst-Type 


Long burst carrying n x 55 long MAC-PDUs bytes or short burst carrying 12 short 
signalling MAC-PDU bytes 


Burst concatenation 


Burst concatenation: Yes or not 


TX MAC PDUs 


Short or long MAC-PDUs to be transmitted per burst 


TX-PHY-Mode 


PHY mode for each transmitted burst 


Power control 


Relative power control signal 


TX-Carrier Freq. Select 


Selection of the TX carrier frequency, load levelling 


Preamble type 


16 or 32 symbols 


PHY power Gap 


Automatic power correction/adaptation in case of change of PHY mode 


Burst transm. Akn. 


Acknowledgment for the successful transmission of a burst 


Tx power margin reserve 


The actual power reserve available 


Power availability for changing 
to a more efficient PHY mode 


The indication from the PHY layer to the DLC layer to notify that the amount of 
available power is sufficient in order to switch to a more spectral efficient PHY 
mode. 


Alarm 


Alarm from DLC for stopping the PHY transmission 
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Table 6: Interface between DLC and PHY in AT (receiver side) 



Signals/Messages 

necepuun oiae 


Detailed parameters 


Timing 


Detection ot ine ueginning or a Trame. rrame stan lime 


rirsi no-ooniroi zone 


First 30 bytes of control zone 


HA MAO-r UUS/UOnTrOI 
z.ui it; uy ico 


Received n x long MAC-PDUs of 55 bytes or control zone bytes 


RS-error flag 


Error flag per each RS decoded block 


CNR, RX-Power 


Measured CNR and RX-power 


Perf. Monitoring 


Information collected by the PHY-layer about link quality following ITU-T 
Recommendations G.821 [3]/G.826 [4]/M.21 00 [6]. 


Alarm, LOS 


Alarm for anomaly from RX-PHY to DLC or Los of synchronization signalling 


TDM/TDMA region ST 


Start time for detecting each TDM or TDMA PHY mode region 


RX-PHY-Mode 


PHY mode for each DL TDM or TDMA PHY mode region 


RX-Carrier Freq. Select 


Selection of the Rx carrier frequency, load levelling 



Some additional remarks: 

NOTE 1: PHY functions include (for transmitter): insertion of zero bits for trellis termination; insertion of padding 
bits to complete a modulation symbol; insertion of padding channel symbols to complete the fixed frame 
duration; creation and insertion of preambles; scrambling; timing for frame and burst duration; 
maintaining of time synchronization. 

NOTE 2: DLC functions include (for transmitter): creation of MAC PDUs or PHY SDUs; creation of control zone 
(including frame number); organization of re-transmissions for ARQ and creation of ARQ entries; 
creation of MAC dummy PDUs; creation of ranging request messages (for AT only); maintaining of 
minimum data rate in UL; segmentation of MAC management messages; encryption and decryption of 
MAC PDU payload. 

The frame structure with a fixed duration of 1 ms is both relevant for DLC and PHY layers. 
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5.2.2 Data units in transmitter and receiver chain 

Figure 9 shows a block diagram of the operations in the transmitter and receiver chain to indicate the relations between 
MAC PDU, RS codewords, FEC blocks and bursts. 
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Figure 9: Block diagram of transmitter and receiver chain 



The ARQ operation is only applicable for the UL direction (where the requests for re-transmissions are sent in DL 
direction as part of the ARQ map in the control zone), but all other operations apply for both transmission directions. If 
an RS codeword carries only one MAC PDU, then MAC PDUs can be re -transmitted individually. Otherwise, if an RS 
codeword carries only several MAC PDUs, then all MAC PDUs of this RS codeword can be re-transmitted. 

The encryption is done individually per MAC PDU, depending on the Initialization Vector (IV) which is generated 
from the frame counter. A MAC PDU to be re-transmitted per ARQ is newly encrypted, i.e. repetitions of the same 
plaintext imply different ciphertext on the air. 
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The RS encoding operation is always present, whereas the inner convolutional encoding operation is only applicable for 
some PHY modes. 

The scrambling operation between encryption and RS encoder (and the inverse de-scrambling) operation is not shown 
in figure 9. 

The mapping of MAC PDUs to the PHY structure (RS codewords, FEC blocks, PHY mode regions and zones) is shown 
in the following figures, firstly for DL and UL directions in case of FDD mode and secondly for the TDD mode. 



5.2.3 Downlink with FDD mode 

The mapping of MAC PDUs to the PHY structure for the DL direction is shown in figure 10 without the TDM A option 
and in figure 1 1 especially for the optional TDMA zone. 
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Figure 10: Transmission of MAC PDUs in DL without TDMA option 

Figure 10 shows the mapping of MAC PDUs to the frame structure in the DL without the TDMA option. The frame 
starts with a preamble of 32 symbols. A control zone follows the preamble containing the DL, ARQ and UL maps. The 
maps indicate events (i.e. PHY modes as well as location and duration within a frame). The DL map defines the TDM 
zone and optionally a TDMA zone. The UL map defines signalling events and different kinds of windows and specific 
user transmission events. The term "length" refers to the duration in the upper parts and to the size in bytes in the lower 
parts of figure 10. 

A TDM zone consists of different PHY mode regions by descending robustness order (i.e. QPSK precedes 16QAM). 
Each PHY mode region time multiplexes data associated with different ATs capable of demodulating and decoding the 
associated PHY mode. As the number of addressed ATs within a PHY mode varies and such does their instantaneous 
DL data rate, all PHY mode region durations can vary from frame to frame. 
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Each PHY mode consists of data which was concatenated (by an outer RS block code and, for some PHY modes, an 
inner convolutional code) encoded using an RS codeword encapsulating four MAC PDUs, except the last RS codeword 
where shortening is applied if the remaining number of PDUs per RS codeword is less than four. In case of an inner 
convolutional code, trellis terminating bits are added to each RS codeword, so an FEC block corresponds to an RS 
codeword. The number of symbols required for the transmission of a PHY mode region depends on the modulation 
scheme. At the end of a PHY mode region, padding bits are added to complete a modulation symbol. To fill up the 
TDM zone, MAC dummy PDUs are inserted (in arbitrary PHY mode regions of the TDM or TDM A zone) and 
additional padding symbols are added at the end of the TDM or TDMA zone to complete exactly the frame. 
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Figure 1 1 : Transmission of MAC PDUs in DL with TDMA option 

Figure 1 1 shows the mapping of MAC PDUs to the frame structure in the DL in case of the additional TDMA zone. The 
term "length" refers to the duration in the upper parts and to the size in bytes in the lower parts of the figure. Optionally, 
a TDMA zone follows the TDM zone. Similar to the TDM zone, the TDMA zone consists of different PHY mode 
regions (bursts) with the following differences: 

• No specific robustness order will be applied. 

• Each PHY mode region starts with a short preamble of 16 symbols. 

Note that the TDMA zone is intended to be used by H-FDD ATs. The H-FDD AT is expected to demodulate and 
decode the beginning of the frame containing the control zone. Depending on its recent UL transmission event, it is 
expected that the H-FDD AT will switch back to DL reception and recover its data in a TDMA PHY mode region 
suitable for its link conditions. 
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The PHY mode region shall be composed of one or more FEC blocks. Every FEC block shall contain 4 MAC PDUs, 
only the last FEC block in a PHY burst shall contain a number of MAC PDUs equal to 1, 2, 3 or 4 in order to complete 
the transmission of the number of MAC PDUs foreseen for the burst. The number of symbols within each FEC block 
depends on the relevant PHY mode. The total length of a burst shall be an integer number of symbols, the last symbol 
shall be padded with bit values equal to as necessary. 

5.2.4 Uplink with FDD mode 

The UL frame is subdivided in: 

• A window for contention-based access (i.e. non-scheduled transmissions) where only bandwidth requests are 
allowed. Only short MAC signalling PDUs with the most robust PHY mode shall be transmitted in the 
contention window. 

• Scheduled bursts (i.e. granted bursts for invited traffic from AT), applies for: 

MAC data PDUs, 

long MAC signalling PDUs, 

short MAC signalling PDUs, 

ranging bursts (always with the most robust PHY mode), 

where each PHY mode can be scheduled for the first three cases). 

The locations of these different parts within an UL frame are indicated by the UIUC entries in the UL map which is 
broadcasted in the control zone in the DL at the beginning of each frame. See clause 8.2.2 for more details on the UL 
frame structure. 

An UL burst for an AT transmission may include more than one MAC PDU or more than one FEC block similar to the 
DL direction. MAC PDUs shall be encapsulated into RS codewords of fixed length. The last RS codeword will be 
shortened in the case where the number of remaining MAC PDUs is less than four. As the AT finishes to transmit its 
UL burst, it may ramp-down its transmitter. This period of time is expected to overlap a ramp-up period of the next AT 
UL burst scheduled for transmission. 

An UL burst can either contain a mixture of MAC data PDUs and long MAC signalling PDUs (and maybe dummy 
PDUs if nothing else is to be transmitted) or one short MAC signalling PDU. In other words, an UL burst with one short 
MAC signalling PDU can not contain a further short MAC signalling PDU or a long MAC PDU. 
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Figure 12 shows the mapping of MAC PDUs to the PHY structure for the UL direction. The term "length" refers to the 
duration and in the lower parts in the figure also to the size in bytes. The options of only one MAC PDU per FEC block 
or one FEC block per preamble are not explicitly shown. 
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Figure 12: Transmission of MAC PDUs in UL 

Note that all UL bursts will be preceded by a guard time and a preamble. The order of the basic UL frame structure 
shown in figure 12 is just an example and it is up to the scheduler in the AP to decide on the order. 

An AT, which the UL map has indicated the existence of an UL transmission event for it, is expected to transmit its data 
at the indicated time. The PHY mode used by the AT for the transmission is specified as well by the UL map. The AT 
begins its transmission with a preamble with length of 16 or 32 symbols (commanded from AP at initialization). 

5.2.5 TDD mode 

There are still some differences for the TDD mode compared to the FDD mode. The frame with a fixed duration of 1 ms 
(as for the FDD mode) is split in a DL subframe and a UL subframe. The subframes are shorter than 1 ms as only a 
portion of the full frame is allocated for each direction. The partitioning into DL and UL subframes can be adaptive 
(i.e. variable over time, to be supported by AP and AT) or non-adaptive as well as synchronous (i.e. between APs of a 
network) or asynchronous. 

At the end of each subframe, a Tx/Rx-switching time is required for switching of the AT from reception to transmission 
or vice versa. 

For the TDD mode, no explicit TDMA zone is necessary, as inherently all ATs are H-FDD operated and no special 
handling is required. 

The SSs for UL transmissions are determined by the UL map as for the FDD mode. 
More information on the TDD mode can be found in clause 8.3.3. 
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5.2.6 Structure of RS codewords and preambles in UL bursts 

Two specific features and theirs combinations can be enabled for the UL transmission (note that in this context a strict 
distinction between RS codewords and FEC blocks is not necessary): 

• None to several midambles per burst: 

No midamble: Only one preamble is used for grouping all FEC blocks in an UL burst. 

Several midambles: Each RS codeword is preceded by its own preamble (in this case, the preamble is 
called midamble), i.e. if there are several FEC blocks for one AT to be transmitted, a new preamble is 
used for each FEC block. This feature could allow for simpler synchronization at the AP, maybe if the 
first preamble is destroyed by UL interference. 

• One or several MAC PDUs per FEC block: 

One: Only one MAC PDU (applies for data PDU or long signalling PDU) instead of four MAC PDUs is 
transmitted by one FEC block. This feature could allow for simpler demodulation at AP and a smaller 
number of re-transmissions for ARQ, since the error detection of RS codewords is effectively related to 
PDUs. 

Several: Each FEC block (except for the last FEC block in an UL burst) carries four MAC PDUs. 

Both features are handled on a per carrier basis and can be time-variant, i.e. they are broadcasted in the GBI message. 
The support of these features is mandatory for the AT and optional for the AP. For all combinations, only one single UL 
map entry is required per UL burst. 

The two features are demonstrated in figure 13 for an example of 5 PDU to be transmitted for the AT under 
consideration. 
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Figure 13: Structure of RS codewords and preambles in an UL burst 

NOTE: Padding to complete a modulation symbol is required at the end of a FEC block if the UL burst is finished 
or continued with another preamble. 
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6 DLC addressing and identities 

6.1 General 

In case of FDD mode, an RF channel is always a pair of DL and UL RF carriers. Only for TDD, an RF channel simply 
reduces to an unpaired single RF channel and both transmission directions are separated by the two subframes of the 
frame. Concerning addressing and logical channel structure, there is no difference between FDD and TDD modes. 

The main identities to be handled in a HA system are as follows: 

• The APC-ID (24 bits) is used to identify the sector during initialization. 

• The AT MAC address (based on MAC-48, 48 bits) is used to identify the AT during initialization and 
authentication. 

• The terminal identity (TID, 10 bits) is used in the control zone for the UL map for the allocation of grants to 
the ATs, in the multiple-TID message. 

• The connection identity (CID, 16 bits) is used in the MAC PDU header for DL and UL to identify the 
connection. Some specific CIDs are used to identify MAC management connections and are thus AT-specific. 

• The connection aggregate identity (CAID, 16 bits) is used in the bandwidth request message and the queue 
status request message. 

• The security associate identity (SAID, 16 bits) is used in security and connection control messages and is 
specified in clause 12. 

6.2 APC Identity (APC-ID) 

The APC-ID (APC Identity) is used to identify the access point controller and so the cell site. The scope is to facilitate 
and speed up the initialization process by identifying the cell site. 

The APC-ID consists of 24 bits. The first 4 bits are used to distinguish between different operators (operator colour 
code) and the remaining 20 bits are used to identify the APC. 

The APC-ID is transmitted in each control zone, i.e. with a period of 1 ms. 

6.3 Access Terminal (AT) Identities 

A long world-wide unique terminal identity of 48 bits related to the terminal equipment (AT MAC address) and a short 
sector- wide unique terminal identity (TID) of 10 bits have to be distinguished. 

6.3.1 AT MAC address (equipment ID based on MAC-48) 

A permanent world-wide unique AT MAC address of 48 bits length is used for terminal identification during the first 
initialization or re-initialization, especially for the initial ranging message and for authentication. 

The AT MAC address is based on MAC-48 (see IEEE 802 in bibliography) and related to the terminal equipment. 
Hence, this is not a logical identity, in case of equipment replacement (e.g. due to an equipment failure) the AT MAC 
address will change. 
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6.3.2 Terminal Identity (TID) 

The terminal identity (TID) of 10 bit is used in the control zone for the UL map entries for the allocation of grants to the 
ATs and also in multiple-TID messages. The TID is unique per carrier. Up to 1024 ATs per carrier are supported with 
regards to addressing. However, due to the noise floor limitation, the number of ATs per sector is limited to 256 and the 
number of ATs per carrier is also limited to 256. 

According to table 7, some specific TIDs shall be used for: 

• UL map entries that indicate the bandwidth request contention window. 

• End of map entries. 

Table 7: Specific TID values (10 bits) 



TID ::= INTEGER (0 .. 1023) 

Normative specifications for specific Tid values: 

— ContentionWindowTid ::= 
EndOfMapTid : := 1 

— normal Tid shall be in the range [2,1023] 



6.4 Connection IDentity (CID) 

The CID (Connection IDentity) is an unstructured field of 16 bits and present in each MAC PDU header for DL and 
UL. 

All CIDs are under full control of the AP both for DL and UL, so the mapping of the VPI field to CID in case of 
cell-based CL is under control of the AP and need not to be specified. 

The CID is unique per RF channel. The CIDs are generated in the AP, both for DL and UL. 

The CIDs are uni-directional and not bi-directional. For all bi-directional unicast data traffic connections, the AP shall 
assign two identical uni-directional CIDs to the two directions. 

According to table 8, specific CIDs shall be used to identify: 

• Broadcast messages (DLonly, important examples are RlcGeneralBroadcastlnf ormation and 
RlcFrequencyList, etc.). 

• Multiple-TID messages RlcMultipleTidBroadcastBasic (DL only, only for basic MAC management 
connections). 

• Broadcasted MAC dummy PDUs (applies for long and short PDUs in DL as well as for short PDUs in UL). 

• Ranging invitation message in DL (where the AT is addressed by its AT MAC address). 



Table 8: Specific CID values (16 bits) 
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For each AT three individual uni-directional CIDs for each direction are used for the MAC management connections. 
Note that the ranges for these CIDs are specified by the present document, although the allocation of CIDs to ATs is 
under full control of the AP in general. 

Additionally, several CIDs are used for multicast connections. Since these are uni-directional connections, the CIDs 
only exist for the DL direction. A specific range for multicast CIDs is not required. 



6.5 Connection aggregate identity (CAID) 

The grouping of connections to connection aggregates shall be under full control of the AP and the result of the 
grouping is communicated to the AT during connection establishment. Later re-groupings are possible. 

Connections belonging to different QoS classes should not be grouped into the same connection aggregate (to allow 
vendor-specific QoS implementations). 

A specific identity for a connection aggregate does exist with 16 bits. For requests, connection aggregates in total are 
addressed by an arbitrary CID inside the connection aggregate, i.e. the CAID is not used for requests per grant 
management field in the MAC PDU header. However, the CAID is used in the payload of the queue status request 
message and the bandwidth request message. 

In order to request bandwidth especially for MAC management messages by using the bandwidth request message 
RlcBandwidthRequest or the queue status request message RlcQueueStatusReq (where both messages 
contain only references to connection aggregates), specific CAID values (which can be selected arbitrarily at AP) are 
provided to the AT during the ranging procedure with the RlcRanginginvitation message. See table 9 for the CAID 
specification. 

Table 9: Specific connection aggregate ID values (16 bits) 

Caid ::= INTEGER ( .. 65535 ) — 16 bit 



7 MAC management messages: 

mapping to MAC management connections, 
transport and list of all messages 

Transport and logical channels are not formally introduced in the present document. 

7.1 Overview of connection types 

Three management connections are established for both directions at AT initialization with AT-specific CIDs: 

• Basic MAC management connection is used to transport shorter, more delay-intolerant (urgent) MAC 
management messages such as ranging requests, signalling for adaptive operation and power control and for 
connection management, etc. 

• Primary MAC management connection is used to exchange longer, more delay-tolerant MAC management 
messages such as key management, etc. 

• Secondary management connection is set up to transfer delay-tolerant standards based information such as 
DHCP, SNMP, TFTP, etc. 

The basic and primary MAC management connections are dedicated for the communication between the DLC protocol 
entities. The secondary management connection is dedicated for the communication between upper layers. 
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In addition to these AT-specific management connections, certain MAC management messages can also be transmitted 
per broadcast: 

• Broadcast connection exists only for DL and is characterized by the broadcast CID. It shall be used with the 
most robust PHY mode (even if all current initialized ATs are able to decode high-level modulation, to 
guarantee the reception of the broadcast channel for new ATs during initialization). 

• An important particular message for the broadcast connection is the GBI message: 

RlcGeneralBroadcastlnformation carrying general information relevant to all ATs and especially the 
description of the current PHY mode set (and new PHY mode set, if applicable). 

Another type of broadcast connection is: 

• Multiple-TID message: 

RlcMultipleTidBroadcastBasic (with the CID MultipleTidBroadcastBasicCid), addressing several ATs. 
The payload of these messages is a packet of pairs (TID, one message for the respective AT), where only 
basic MAC management messages are carried. The specification of the multiple-TID messages is shown 
in table 10 and also illustrated in figure 14. 

Table 10: Multiple-TID message 



RlcMultipleTidBroadcastBasic ::= SEQUENCE ( SIZE ( 1 . .50) ) OF PairTidMessageBasic 

PairTidMessageBasic ::= SEQUENCE { 

tid Tid, 

messagesForTidPackingBasic MessagesForTidPackingBasic 

} 

MessagesForTidPackingBasic ::= CHOICE { 
— see Table in clause 7.4.3 

} 



Furthermore, several: 

• Multicast connections can be set up for specific groups of ATs to transport multicast MAC data PDUs. The 
multicast CIDs have the same generic format as all other CIDs. 

Broadcast information can be transmitted in the broadcast connection (e.g. GBI message or other MAC management 
messages) or in the control zone. The control zone appears at the beginning of each frame ("fast channel"), whereas the 
GBI message is usually transmitted in long intervals only ("slow connection"). 

All MAC management messages transmitted in the three MAC management connections or in the broadcast connection 
are carried with the same generic MAC PDU format (MAC signalling PDU) as used for the regular traffic (MAC data 
PDU). 

The basic, primary and secondary MAC management connections are of unicast type and can be transmitted with any 
PHY mode in DL or UL. The broadcast connection (but not the multicast connections) shall be transmitted always with 
the most robust PHY mode in the DL to guarantee their reception by all ATs. 



7.2 Transport of MAC management messages with MAC 
Signalling PDUs 

Long (both DL and UL) as well as short (UL only) MAC signalling PDUs are specified, see clause 8.1 for the exact 
formats. These MAC signalling PDUs and the MAC data PDUs (and additionally MAC dummy PDUs) are identified 
by the PT field in the generic MAC PDU header. 
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7.2.1 



Some general rules 



Some general rules for the use of MAC signalling PDUs are summarized below. 

• Opportunities for transmitting with both long and short MAC signalling PDUs in the UL can be granted to the 
AT. It should be noted that grants for MAC data PDUs and long MAC signalling PDUs can not be 
distinguished in the UL map. 

• The AT can issue requests for bandwidth (both MAC data PDUs and long MAC signalling PDUs). Specific 
requests for short MAC signalling PDUs are also possible via the RSB bit in the MAC PDU header. 

• The AT can use granted bandwidth for sending a MAC management message, but this shall be in the form of a 
long MAC signalling PDU (instead of a MAC data PDU) or short MAC signalling PDU. Specific rules for 
using granted short MAC signalling PDUs are summarized in clause 7.2.3. 

• In the bandwidth contention window only short MAC signalling PDUs are allowed with PHY mode #1 
carrying the message for bandwidth requests. However, the bandwidth request message can also be sent in 
granted short UL bursts. 

• Short MAC signalling PDUs shall be used for granted short bursts and for the bandwidth contention window 
as well as for granted ranging bursts (during first initialization or re-initialization). 

• It is possible to combine several messages into one long MAC signalling PDU for the same AT (applies for 
DL) or from the same AT (applies for UL) by packing. The short MAC signalling PDU (UL only) contains 
always only one or no message (to avoid problems with packing). 

• It is possible to combine messages for several ATs (applies only for DL) into one MAC signalling PDU as 

RlcMultipleTidBroadcastBasic message. 

• Segmentation of MAC management messages is possible for DL and UL directions, but not in combination 
with packing or multiple-TID message. 

• An UL burst contains either one or several long MAC PDUs (can be a mixture of long MAC signalling PDUs 
and MAC data PDUs and MAC dummy PDUs, can consist of several FEC blocks) or exactly one short MAC 
signalling PDU (a specific UL ranging burst with extra guard time is specified for short MAC signalling PDUs 
carrying ranging requests). A mixture of short and long MAC PDUs or several short MAC signalling PDUs in 
one UL burst shall not be supported. 

• If the AT receives grants for transmission without having any data (traffic or signalling) to transmit, then it 
shall send long or short MAC dummy PDUs (as specified by the grant). 

• It is up to the schedulers in the AP (giving grants for UL) and the AT (using grants for UL) to determine how 
MAC management messages shall be transmitted, e.g. with long or short MAC signalling PDUs (if 
applicable). Hence there is no pre-defined binding between MAC management messages and MAC signalling 
PDUs in the UL (with some exceptions, see clause 7.2.3). 

• Padding shall be used to fill up any unfilled payload part of any MAC signalling PDU. 



The long MAC signalling PDUs are created in the DLC layer. 

Short (i.e. compared to 5 1 bytes) MAC management messages shall have the option to be packed and transmitted in one 
long MAC signalling PDU as specified in clause 7.3. This applies both for DL (for the same AT) and UL (from the 
same AT). Additionally, several short messages for different ATs can be packed together in one multiple-TID message. 
All messages that are allowed to be packed are listed in clause 7.4. 

Long (i.e. longer than 51 bytes) MAC management messages shall be segmented (SAR, segmentation and reassembly, 
part of the MAC sublayer) as specified in clause 7.3. Examples for very long MAC management messages are 
asymmetric keys and the AT certificate. 



7.2.2 



The use of long MAC signalling PDUs 
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Two types of long MAC signalling PDUs are distinguished by the PT field in the header: 

• Non-segmented long MAC signalling PDU carries one MAC management message or a packet of several 
MAC management messages, if the total length is smaller than or equal to 51 bytes (after encoding). 

• Segmented long MAC signalling PDU carries segments of long MAC management messages. The payload 
of 5 1 bytes consists of 1 byte for segmentation control (SCF) and up to 50 bytes for the segment. 

Packing and segmentation shall not be combined. 

7.2.3 The use of short MAC signalling PDUs 

As for long MAC signalling PDUs, the short MAC signalling PDUs are also created in the DLC layer. 

Short signalling PDUs shall be used only in the UL and shall be precluded for the DL. A burst containing a short MAC 
signalling PDU contains only this one short MAC signalling PDU, i.e. several short MAC signalling PDU within one 
burst or a mixture with long MAC signalling PDUs or MAC data PDUs shall be precluded. The following rules shall be 
applied when using short MAC signalling PDUs: 

• Short MAC signalling PDUs shall be used to carry the following types of MAC management messages, where 
only granted bursts are allowed for transmission (see exception for bandwidth request below) and all PHY 
mode are allowed (see exception for ranging request below): 

Bandwidth request message RlcBandwidthRequest, possible not only in granted short UL bursts 
but also in the bandwidth request contention window. 

Queues status reply message RlcQueueStatusRsp, but only after reception of the queue status 
request message RlcQueueStatusReq. 

Measurement report message RlcMeasurementReportData, used for the signalling for ATPC and 
DL PHY mode change, where the message can be initiated by: 

i) changed link conditions measured by the AT, 

ii) AP request, or 

iii) expiration of period. The measurement report can also be transmitted in a long MAC signalling 
PDU. 

Ranging request message RlcRangingReq, but only with PHY mode #1 and only for granted UL 
ranging bursts (i.e. not for granted normal short bursts). 

Short MAC dummy PDU. 

All other messages that are short enough to fit into a short MAC signalling PDU. 

• Any UL burst, if used to transmit short MAC signalling PDUs, shall contain only one short MAC signalling 
PDU. 

• If short MAC signalling PDUs are to be transmitted in scheduled bursts, the UIUC entry of the UL map shall 
be one that indicates short MAC signalling PDUs (and not long PDUs) or ranging bursts. 

• Packed messages shall not be transmitted with short MAC signalling PDUs. 
Three additional rules are mandatory: 

• After reception of the message RlcQueueStatusReq, the next granted short burst shall be used for the 
message RlcQueueStatusRsp. 

• If periodic measurement reports are commanded, then the report RlcMeasurementReportData shall be 
sent in the next granted short PDU after expiration of the report period. 
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In case that the messages RlcQueueStatusRsp and RlcMeasurementReportData shall be 
transmitted at the "same" time, the message RlcQueueStatusRsp shall have a higher priority than the 
message RlcMeasurementReportData. However, the AP shall be smart enough to grant enough short 
UL bursts for such conditions. 

The AT can also request a grant for a short UL burst with the RSB bit in the MAC PDU header. This shall not 
affect the three rules stated above. 



7.3 Transport of MAC management messages 
(packing, encoding, segmentation) 

7.3.1 Overview of message formats 

The principal formats for MAC management messages are outlined in figure 14. The message length can range from 
very few bytes to 256 bytes (corresponding to a 2 048-bit asymmetric key) or more. Moreover, the length can be 
variable for the same message types due to optional fields. Several messages can be packed. The message length is 
increased by PER encoding. 



one 
message 



one 
message 



I 



packet 
of several messages 



I 



TID (10 bit) 





one 
message 




one 
message 


I 


one 
message 















shall be transmitted with a 

short MAC signaling PDU (only UL) 

or a long MAC signaling PDU (UL or DL) 



shall be transmitted with a 
long MAC signaling PDU 



packet message, 

to same AT (DL)/from same AT (UL), 

only for basic MAC management connection 



multiple-TID message (only DL), 
shall be transmitted with a 
long MAC signaling PDU 




shall be segmented and transmitted 
with several segmented long MAC 
signaling PDUs 



51 byte 



Figure 14: MAC management message formats 

There shall be no pre-defined binding between MAC management messages or MAC signalling PDUs and PHY modes 
(except for the cases mentioned in clause 7.2.3). All PHY modes can be used for long MAC signalling PDUs in DL and 
UL as well as for the scheduled short MAC signalling PDUs in the UL. 

Very long MAC management messages shall be segmented and carried by several long MAC signalling PDUs. There is 
a general instance for SAR (Segmentation and Reassembly) in the MAC sublayer, applicable for all types of messages 
as shown in figure 4. 
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7.3.2 Overview of packing, encoding and segmentation 

An overview of packing, ASN. 1 encoding with PER (Packet Encoding Rule) [7] and S AR within the transmitter path 
and the mapping to long or short MAC signalling PDUs is shown in figure 15. 



message 




message 





message 



Packing only 

• for same MAC mgmt. conn. 

• if result after encoding is 
shorter than or equal to 51 bytes 

•if allowed for specific message 



encoder adds message 
type and lengths fields 
where needed 




> 51 bytes before SAR 
SCF is added to each segment 



51 bytes 
(long PDU, 
segmented) 



51 bytes 
(long PDU, 
segmented) 



51 bytes 
(long PDU, 
not segmented) 



padding 
(if required) 

...*y. 



8 bytes 
(short PDU, 
only UL) 



Legend: H 

SCF 
SAR 
segment 



Header (3 bytes for DL, 4 bytes for UL) 
Segmentation Control Field (1 byte) 
Segmentation and Reassembly 
segment of an encoded message 



NOTE: Packing and SAR shall not be combined. 

Figure 15: Overview of packing, encoding, SAR and mapping on MAC signalling PDUs 
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7.3.3 Encoding rule 

PER encoding with byte alignment shall be applied to each message according to [7]. There is no kind of pre-defined 
classification of messages according to their lengths. 

NOTE: For all messages that are specified to be transmitted with a short MAC signalling PDU it is guaranteed 

that the message length after PER encoding (including message type indication) is shorter than or equal to 
8 bytes. 

7.3.4 Packing of MAC management messages 

Packing of messages is possible for DL and UL if applicable according to the message type. Packing is only allowed for 
basic MAC management connections. 

Packing is not allowed in combination with segmentation (applies for DL and UL) and for the multiple-TID message 
(applies only for DL). 

7.3.5 Segmentation and Reassembly (SAR) 

No overhead is introduced by SAR since the SCF (Segmentation Control Field) is only present for segmented long 
MAC signalling PDUs. The MAC PDU header contains no kind of SCF itself but an indication of SCF by the PT field, 
i.e. segmented or non-segmented long MAC signalling PDU. 

The segments shall have a length of 50 bytes (the last segment can be shorter). SAR shall not be applied for packet 
messages (i.e. the result of packing shall be shorter than or equal to 51 bytes). 

The 1-byte SCF (Segmentation Control Field) consists of a 2-bit field SI (Segmentation Indication) as defined in 
table 1 1 and a 6-bit field SSN (Segmentation Sequence Number). 

Table 11: Definition of Segmentation Indication (SI, 1 byte) 



Segment 


SI 


First fragment 


00 


Continuing fragment 


01 


Last fragment 


10 


undefined 


11 



The segmentation control field (SCF) is shown in figure 16. 





8 


7 


6 


5 


4 


3 

(LSB) 


2 


1 


octett 1 


SSN 

(segmentation sequence number) 


SI 

(segmentation 
indication) 



Figure 16: Definition of Segmentation Control Field (SCF, 1 byte, left bit transmitted first) 

7.4 List of protocol primitives and mapping of messages to 
connections (normative) 

7.4.1 List of all MAC management messages 

Table 12 provides an overview and a short description of all MAC management messages. The detailed message 
contents are given in annex B. 
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Legend for "connection" column in table 12 : 

• = broadcast (only for DL) 

• 1 = basic MAC management connection (AT-specific) 

• 2 = primary MAC management connection (AT-specific) 

• 3 = secondary management connection (AT-specific) 

• p = allowed for packing 

• m = allowed for multiple-TID message 

• R-NR = direction from requesting to non-requesting entity 

• NR-R = direction from non-requesting to requesting entity 



Table 12: List of MAC management messages (protocol primitives) 



Name 


Direction 


Connection 


Description and remarks 


Broadcast messages 


RIcGeneralBroadcastlnformation 
(GBI message) 


DL 





Broadcast information (Frequencies, operation 
modes, frame offset, contention resolution 
parameters, timers, PHY mode set descriptor(s) 


RIcFrequencyList 


DL 





Frequency list 


RIcMultipleTidBroadcastBasic 


DL 





Addresses several ATs, contains a packet of (TID, 
basic MAC management message) pairs 


Request-grant messages 


RIcBandwidthReq 


UL 


1 


Bandwidth request, shall be used in granted short 
PDUs or in bandwidth request contention window 


RIcQueueStatusReq 


DL 


1 , p, m 


Request to report the queue status of listed CAs 


RIcQueueStatusRsp 


UL 


1 


Response, containing the queue lengths, to be 
transmitted in next granted short PDU 


Initialization control messages 


RIcRanginglnvitation 


DL 


1 


Invitation to initial ranging (binding between MAC 
address and TID, allocation of CIDs, start of 
ranging). Multiple-TID message not possible 


RIcRangingReq 


UL 


1 


Ranging request in granted UL ranging burst, 
contains formally EGT, transmitted with increasing 
or adapted power 


RIcRangingContinue 


DL 


1 , m 


Response from AP, contains power and timing 
offset information and indicates continuation of 
ranging 


RIcRangingSuccess 


DL 


1, m 


Response from AP, contains power and timing 
offset information and indicates termination of 
ranging, informs about termination of initialization 


RIcRangingAck 


UL 


1 


Acknowledgement of reception of 
RIcRangingSuccess, in granted UL ranging burst 


RIcPhyCapabilitiesReq 


DL 


1 , p, m 


AP request to send RlcPhyCapabilitieslnfo 


RlcPhyCapabilitieslnfo 


UL 


1 

non-PTC 


AT informs about its optional PHY capabilities, PTC 
not allowed 


RlcPhyCapabilitiesCnf 


DL 


1, p, m 


AP commands PHY features to be used, informs 
about termination of initialization 


RIcOtherCapabilitiesReq 


DL 


1 , p, m 


AP request to send RlcOtherCapabilitieslnfo 


RlcOtherCapabilitieslnfo 


UL 


1 


AT informs about its optional other capabilities, PTC 
not allowed 


RlcOtherCapabilitiesCnf 


DL 


1, P, m 


AP commands other features to be used, informs 
about termination of initialization 


Radio resource control messages 


RlclnitializationCmd 


DL 


1, p, m 


AP to command a new first/re-initialization or to 
reject AT from network or to stop/re-start UL 
transmission 


RIcMeasurementReportData 


UL 


LP 


Measurement report or request for DL PHY mode 
change, shall be transmitted in granted short 
(packing not allowed) or long (packing allowed) 
PDUs 
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Name 


Direction 


Connection 


Description and remarks 


Broadcast messages 


RIcDownlinkPhyModeChange 


DL 


1 , p, m 


Announcement of DL PHY mode change 


RIcDownlinkPhyModeChangeAck 


UL 


LP 


Acknowledgement of reception of 
RIcDownlinkPhyModeChange 


RlcUplinkCorrection 


DL 


1, p, m 


Correction step for UL power and timing 
(incremental) and possible request for 
measurement report 


RIcMeasurementReportCriterium 


DL 


1 , p, m 


AT-specific update of period for measurement 
reports 


RIcHandoverCmd 


DL 


1, m 


Command for handover, contains the new RF 
channel. No other messages for AT at this time 


RIcHandoverCnf 


UL 


1 


Acknowledgement of reception of RIcHandoverCmd 


Security control messages 


RIcAuthCmd J 


DL 


2 


Initiates authentication 


RIcAuthManufacturerlnfo 


UL 


2 


Contains the AT manufacturer's X.509 Certificate, 
issued by an external authority 


RIcAuthReq 


UL 


2 


To request an AK and list of authorized SAIDs 


RIcAuthReply 


DL 


2 


To reply an AK and a list of authorized SAIDs 


RIcAuth Reject 


DL 


2 


Rejection of an RIcAuthReq 


RIcAuthlnvalid 


DL 


2 


Unsolicited indication or a response to an UL 
message 


RIcTekReq 


UL 


2 


Requesting a TEK for the privacy of one of its 
authorized SAIDs 


RIcTekAl location 


DL 


2 


Carrying the two active sets of traffic keying 
material for the SAID 


RIcTekReject 


DL 


2 


Indication that the SAID is no longer valid and no 
key will be sent 


RIcTeklnvalid 


DL 


2 


If AP determines that the AT uses an invalid TEK 
for encryption 


Connection control messages 


RIcConnectionAdditionlnit 


UL 


LP 


Request issued by the AT for establishing a new 
connection 


RIcConnectionAdditionSetup 


DL 


1 , p, m 


Message issued by the AP for establish a new 
connection or answering a request coming from an 
AT 


RIcConnectionAdditionAck 


UL 


LP 


Acknowledgement of RIcConnectionAdditionSetup 
message 


RlcConnectionChangelnit 


UL 


LP 


Request issued by the AT for change some 
parameters of an already established connection 


RlcConnectionChangeSetup 


DL 


1, p, m 


Message issued by the AP for change some 
parameters of an already established connection or 
answering a request for change some parameters 
of an already established connection coming from 
an AT 


RIcConnectionChangeAck 


UL 


LP 


Acknowledgement of RlcConnectionChangeSetup 
message 


RIcConnectionDeletionlnit 


R-NR 


1,P, 
m (DL) 


Message initializing a Connection Deletion 
procedure 


RIcConnectionDeletionAck 


NR-R 


1,p, 
m (DL) 


Acknowledgement of RIcConnectionDeletionlnit 
message 


Packed messages 


PackedMessageDownlinkBasic 


DL 


1 


Packet of basic MAC management messages for 
DL 


PackedMessageUplinkBasic 


UL 


1 


Packet of basic MAC management messages for 
UL 
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7.4.2 Messages for packing 

Table 13: List of DL basic MAC management messages for packing 

Name 

RIcQueueStatusReq 

RIcPhyCapabilitiesReq 

RlcPhyCapabilitiesCnf 

RIcOtherCapabilitiesReq 

RlcOtherCapabilitiesCnf 

RlclnitializationCmd 

RIcDownlinkPhyModeChange 

RlcUplinkCorrection 

RIcMeasurementReportCriterium 

RIcConnectionAdditionSetup 

RlcConnectionChangeSetup 

RIcConnectionDeletionlnit (if DL) 

RIcConnectionDeletionAck (if DL) 



Table 14: List of UL basic MAC management messages for packing 

Name 

RIcMeasurementReportData 

RIcDownlinkPhyModeChangeAck 

RIcConnectionAdditionlnit 

RIcConnectionAdditionAck 

RlcConnectionChangelnit 

RIcConnectionChangeAck 

RIcConnectionDeletionlnit (if UL) 

RIcConnectionDeletionAck (if UL) 



7.4.3 Messages for multiple-TID 

Table 15: List of DL basic MAC management messages for multiple-TID message 

Name 

RIcQueueStatusReq 

RIcRangingContinue 

RIcRangingSuccess 

RIcPhyCapabilitiesReq 

RlcPhyCapabilitiesCnf 

RIcOtherCapabilitiesReq 

RlcOtherCapabilitiesCnf 

RlclnitializationCmd 

RIcDownlinkPhyModeChange 

RlcUplinkCorrection 

RIcMeasurementReportCriterium 

RIcHandoverCmd 

RIcConnectionAdditionSetup 

RlcConnectionChangeSetup 

RIcConnectionDeletionlnit (if DL) 

RIcConnectionDeletionAck (if DL) 
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7.4.4 Overview of Connections 

Table 16: Overview of connections and related parameters 



Connection type 


Directi 
on 


Identification 


PHY 

mode 


UL PDU 
length 


PT 


data 


both 


DataCid (per AT, allocated to CA) 


all 


L 





basic MAC mgmt 


both 


BasicCid, BasicCaid (per AT) 


all 


LorS 


1, 2, 4 


primary MAC mgmt 


both 


PrimaryCid, PrimaryCaid (per AT) 


all 


LorS 


1, 2, 4 


secondary mgmt 


both 


SecondaryCid (per AT) 


all 


L 


1 


broadcast 

(e.g., GBI message) 


DL 


BroadcastCid=0 


1 




1 


control zone 
(not a connection) 


DL 


frame preamble, DIUC, UIUC, 
EndOfMapTid=1 







n/a 


multiple-TID 


DL 


MultipleTidBroadcastBasicCid=1 


all 




1 


multicast 


DL 


DataCid (per AT group) 


all 







ranging burst 
(not a connection) 


UL 


RangingCid=4 (per AT), UIUC 


1 


Ranging 
burst 


4 


Contention window 
(RIcBandwidthRequest) 


UL 


ContentionWindowTid=0, UIUC 


1 


S 


4 


MAC dummy PDU 
(not a connection) 


both 


DummyCid=3 (per AT) 


all 


LorS 


3, 5 



Legend: UL PDU length: L=long, S=short 

PT: 0=data, l=long non-seg, 2=long seg, 3=long dummy, 4=short, 5=short dummy 



7.5 List of service primitives (informative) 

The HA DLC layer supports 18 different service primitives dedicated to connection control functionality. These 
primitives are exchanged at the DLC Service Access Point and can be divided up into four different groups according to 
the related procedure. 

The complete list is reported in table 17. The detailed message contents are given in annex B. Legend for "direction" 
and "type" columns: 

Up: from DLC layer to CL, 

• Down: from CL to DLC layer, 

• Ctrl: primitive that generates or is generated by a basic MAC management message at DLC level, 

• Data: primitive that transports data to be mapped into the relevant connection ID at DLC level. 
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Table 17: List of connection control service primitives 



Primitive 
Name 


Direction 


Type 


Description and remarks 


Connection Establishment 


DIcConnectionAdditionlnitReq 


Down 


Ctrl 


Generates an RIcConnectionAdditionlnit message at DLC 
layer 


DIcConnectionAdditionlnitlnd 


Up 


Ctrl 


Generated by the RIcConnectionAdditionlnit message 


DIcConnectionAdditionReq 


Down 


Ctrl 


Generates an RIcConnectionAdditionSetup message at 
DLC layer 


DIcConnectionAdditionlnd 


Up 


Ctrl 


Generated by the RIcConnectionAdditionSetup message 


DIcConnectionAdditionRsp 


Down 


Ctrl 


Generates an RIcConnectionAdditionAck message at DLC 
layer 


DIcConnectionAdditionCnf 


Up 


Ctrl 


Generated by the RIcConnectionAdditionAck message 


Connection Change 


DIcConnectionChangelnitReq 


Down 


Ctrl 


Generates an RlcConnectionChangelnit message at DLC 
layer 


DlcConnectionChangelnitlnd 


Up 


Ctrl 


Generated by the RlcConnectionChangelnit message 


DIcConnectionChangeReq 


Down 


Ctrl 


Generates an RlcConnectionChangeSetup message at 
DLC layer 


DlcConnectionChangelnd 


Up 


Ctrl 


Generated by the RlcConnectionChangeSetup message 


DIcConnectionChangeRsp 


Down 


Ctrl 


Generates an RIcConnectionChangeAck message at DLC 
layer 


DlcConnectionChangeCnf 


Up 


Ctrl 


Generated by the RIcConnectionChangeAck message 


Connection Release 


DIcConnectionDeletionReq 


Down 


Ctrl 


Generates an RIcConnectionDeletionlnit message at DLC 
layer 


DIcConnectionDeletionlnd 


Up 


Ctrl 


Generated by the RIcConnectionDeletionlnit message 


DIcConnectionDeletionRsp 


Down 


Ctrl 


Generates an RIcConnectionDeletionAck message at DLC 
layer 


DIcConnectionDeletionCnf 


Up 


Ctrl 


Generated by the RIcConnectionDeletionAck message 


Data primitives 


DIcDataReq 


Down 


Data 


This primitive is responsible of passing data from CL to the 
DLC 


DIcDatalnd 


Up 


Data 


This primitive is responsible of receiving data from CL to 
the DLC 



8 Multiplexing and MAC frame structure 

This clause is structured as follows: 

MAC PDU formats; especially the MAC PDU headers for DL and UL directions, for MAC data PDU, MAC 
dummy PDU, long and short MAC signalling PDU. 

• Frame Structure for DL and UL directions. 

• Support of FDD and TDD modes and H-FDD operation. 

• Structure of maps for DL and UL. 

• Support of ARQ (operation of ARQ, frame structure and map for ARQ). 

• Detailed structure of the control zone. 

• MAC Support of PHY layer (time relevance of the maps, map protection, PHY mode set description). 

The mapping of the MAC PDUs to the PHY structure (i.e. to codewords, PHY mode regions and zones) is described in 
clause 5.2 about the interface between DLC and PHY layers. 
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8.1 MAC PDU format 

8.1.1 Overview 

The MAC PDU is the data unit exchanged between the MAC sublayers of AP and AT. The MAC PDU shall have a 
fixed length in bytes, but a variable duration and a variable length in symbols due to the use of adaptive PHY mode 
(i.e. adaptive modulation and coding schemes). 

Four MAC PDU types are defined, each consisting of the MAC PDU payload part and the MAC PDU header as shown 
in figure 6 and figure 7: 

• MAC data PDU: shall be used to carry data only. The total length is 54 bytes for DL and 55 bytes for UL 
where for both directions the traffic payload is fixed to 51 bytes. In case of a cell-based CL, this is suitable for 
carrying ATM cells, corresponding to 48 bytes ATM payload plus 3 bytes header (i.e. full ATM header except 
HEC and VPI field). 

• MAC dummy PDU: the long MAC dummy PDU is a specific MAC PDU with the same total length as the 
MAC data PDU to fill up the DL TDM zone if not enough MAC PDUs are to be transmitted or to fill up an 
UL burst if more MAC PDU have been granted than are available for transmission. The short MAC dummy 
PDU exists only in the UL with a total length of 12 bytes and is used if more grants for short PDUs are given 
than short MAC signalling PDUs are available for transmission. 

• Long MAC signalling PDU: shall have the same length as the MAC data PDU with 51 bytes for the payload 
part. Two subtypes have to be distinguished (both for DL and UL): 

The segmented long MAC signalling PDU shall be used to carry the segments of long (unpacked) 
messages after SAR, i.e. the PT field in the PDU header indicates that the first byte of the payload 
contains segmentation information. The length of the segments itself are limited to 50 bytes. 

The non-segmented long MAC signalling PDU shall be used to carry one message or a packet of 
several messages. The length of the payload is limited to 51 bytes. 

• Short MAC signalling PDU: carries only one message, exits only in the UL. The payload length is 8 bytes 
and the total length is 12 bytes. 

Encryption for privacy is only applied for MAC data PDUs (i.e. for PT = 000) and only for the 51 bytes of the payload 
part and only for unicast connections. 

8.1.2 MAC PDU header 

The MAC PDU headers for DL and UL transmissions are different and shown in table 18 for the DL with a length of 
3 bytes (applies for MAC data PDU, MAC dummy PDU, long MAC signalling PDU) and table 19 for the UL with a 
length of 4 bytes (applies for MAC data PDU, MAC dummy PDU, long MAC signalling PDU, short MAC signalling 
PDU). The difference in the length is caused by the additional GM field required in the UL header. 



Table 18: MAC PDU header for DL (3 bytes, left bit transmitted first) 



Number of bits 


Field description 


3 


PT = PduType 


2 


EKS = EncrKeySeq 


16 


CID = Connld 


1 


IVP = IndVarPdu 


2 


Rsvd = reserved 
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8 


7 


6 


5 


4 


3 


2 


1 


octet 1 








C 


D 






LSB 


octet 2 


CID 


octet 3 


PT 


EKS 


IVP 


Rsvd 



Table 19: MAC PDU header for UL (4 bytes, left bit transmitted first) 



Number of bits 


Field description 


3 


PT = PduType 


2 


EKS = EncrKeySeq 


16 


CID = Connld 


8 


PB = Piggyback 


1 


PM = poll-me 


1 


RSB = request for short UL burst (for MAC signalling PDU) 


1 


IVP = IndVarPdu 





8 


7 


6 


5 


4 


3 


2 


1 


octet 1 








C 


D 






LSB 


octet 2 


CID 


octet 3 


PT 


EKS 


IVP 


PM 


RSB 


octet 4 


PB 



The EKS field is required for the key exchange procedure, hence it shall be ignored for all PDU types except MAC data 
PDUs. If a connection is not encrypted, the EKS field shall be set to "00" and shall be ignored by the receiving side. 

The CID field is required to identify the connection. An exception appears for MAC dummy PDUs (see below). 

The combination of PB, PM and RSB is also called GM (Grant management field 10 bits) and carries information 
required for the request-grant mechanism. The piggyback field (PB, 8 bit) describes the number of PDUs in the queue 
for the connection aggregate the CID belongs to. The poll-me bit (PM, 1 bit) refers to the AT that transmits the MAC 
PDU. The request bit for a short UL burst (RSB) can be used to request a transmit opportunity for a short MAC 
signalling PDU. The PM and RSB bits are described in clause 9.4. 

The MAC PDU types are distinguished by the PT (PDU Type) field of 3 bits as shown in table 20. Not all types are 
present in both directions. 
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Table 20: PT field for MAC PDU headers 



PT pattern 


Description 


Direction 


000 


MAC data PDU 


DLand UL 


001 


long MAC signalling PDU (not segmented) 


DLand UL 


010 


long MAC signalling PDU (segmented) 


DLand UL 


011 


long MAC dummy PDU 


DLandUL 


100 


short MAC signalling PDU 


UL 


101 


short MAC dummy PDU 


UL 


110 


reserved 




111 


reserved 





The IVP (Indication of variable MAC PDU) bit shall be set to zero. 

• If a MAC PDU is received by the AT where the IVP bit is unequal to zero, then this MAC PDU and all the 
following MAC PDUs until the end of the PHY mode region shall be discarded. 

• If a MAC PDU is received by the AP where the IVP bit is unequal to zero, then this indicates a malfunction of 
the AT and the AT shall be re-initialized (and should be removed from the network in case of repeated failure). 

Note that MAC PDUs for multicast connections are not distinguished from MAC PDUs for unicast connections by the 
PT field, this applies for all types of MAC PDUs. 

Two bits in the MAC PDU header for the DL are reserved for future upgrades and shall be set to zero. 

Note that ARQ does not need additional fields in the MAC PDU header. 

NOTE: For the PHY layer, the MAC PDUs appear as coherent units, i.e. the PHY layer can not distinguish 
between the header and the payload of a PHY SDU. 

8.1.3 MAC data PDU 

This is the main type of all MAC PDUs, so the header is optimized for this MAC PDU type. 

Encryption for privacy is applied only for all unicast MAC data PDUs, and only for the 5 1 bytes of the payload part. 
Multicast MAC data PDUs shall not be encrypted. 

8.1 .4 Long MAC signalling PDU 

The long signalling PDU shall be used to carry a MAC management message only, both for DL and UL directions. In 
the payload part, it may carry one message (can also be a packet of several messages or a multiple-TID message) or a 
segment of a long message. 

The length of long MAC signalling PDUs is the same as for MAC data PDUs, i.e. 51 bytes for the payload and 3 bytes 
or 4 bytes for the header in DL or UL, respectively, where the same header formats are used as for MAC data PDUs. 

The indication of the message type is contained in the encoded message. 

Segmentation of long messages by SAR (Segmentation and Reassembly) applies only for long MAC signalling PDUs, 
both for DL and UL. Only very few messages require for segmentation, e.g. the transmission of public asymmetric keys 
with 2 048 bit. The indication of segmentation is done per PT field in the header. In case of non-segmented long MAC 
signalling PDUs, all 5 1 bytes of the payload can be used to carry the message. In case of segmented long MAC 
signalling PDUs, the first byte of the payload contains the segmentation control (SCF) information, so the message 
segment is limited to 50 bytes. 

The payload of long MAC signalling PDUs shall not be encrypted. 

8.1 .5 Short MAC signalling PDU 

The short MAC signalling PDU shall be used to carry signalling messages only. They are only used in the UL direction. 

The length of short MAC signalling PDUs is 8 bytes for the payload plus 4 bytes for the header, where the same header 
format is used as for MAC data PDUs or long MAC signalling PDUs in the UL. 
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NOTE: In some cases the type of the message is known in advance from the appearance in a specific window 
(e.g. bandwidth request message in bandwidth request contention window). 

The payload of short MAC signalling PDUs shall not be encrypted. 

8.1 .6 Long and short MAC dummy PDU 

MAC dummy PDUs are generated in the DLC layer. 

The payload and header format of long MAC dummy PDUs is identical to the MAC data PDU format. The long MAC 
dummy PDU shall be used in DL or UL to fill up: 

• The DL TDM zone if not enough MAC data PDUs are to be transmitted. They can be transmitted with any 
PHY mode, i.e. within any PHY mode region of the TDM or TDMA zone. 

• An UL burst if more MAC PDU have been granted than are available for transmission (usually, the AP 
scheduler knows the number of MAC PDU in the AT, however, it is possible that grants are given for ARQ 
re-transmissions which cannot be used for non-ARQ connections). 

The payload and header format of short MAC dummy PDUs is identical to the short MAC signalling data PDU format. 
The short MAC dummy PDU shall be used in the UL to fill up: 

• An UL burst if more grants for short PDUs have been received than are required for transmission of short 
MAC signalling PDUs. 

Grants for long or short PDUs can also be given by the AP to enforce the AT to transmit in any case. The AT shall 
transmit if grants are received, maybe with long or short (according to the grant) MAC dummy PDUs (if no other data 
is available). This allows the AP to measure the properties of the UL radio link. 

The content of the header of all MAC dummy PDUs is ignored in the receiver after reading the PT field. A MAC 
dummy PDU shall be both marked by the PT field and a specific "MAC dummy CID". 

The 51 byte payload of a long MAC dummy PDU shall be identical to an ATM idle cell, i.e. the first three bytes 
corresponding to the compressed ATM header shall be zero with the exception of 1 for the CLP bit, and the content of 
the information field is 01 10 1010 repeated 48 times. 

The 8-byte payload of a short MAC dummy PDU shall be set to zero. 

MAC dummy PDUs shall not be encrypted. 

8.2 Frame structure 

The frame structure shall be flexible enough to support either the FDD or the TDD operational mode. With reference to 
the FDD mode, the frame structure gives the possibility to support in the same frame both the FDD ATs as well as the 
H-FDDATs. 

The transmissions of AP and AT shall be structured in frames of fixed length. The frame structure is relevant for the 
DLC layer (especially with regards to scheduling and multiplexing) as well as for the PHY layer (especially with 
regards to synchronization and preambles). The frame duration shall be fixed to 1 ms, both for DL and UL directions, 
and shall be independent of the FDD and TDD mode and the H-FDD operation. 

For FDD, the frames for DL and UL shall be synchronized in time with a fixed frame offset (FO), where FO is 
configurable by the AP. An offset of zero would mean an exact alignment (i.e. on the AP antenna, the UL frame starts 
at the same time as the DL frame starts), however, the minimum FO shall be at least 0,4 ms, since this corresponds to 
about the maximum length of the control zone in DL under worst-case conditions, i.e. the UL frame does not start 
earlier than the end of the UL map where also some extra time for the decoding of the UL map should be spent. 
Formally, FO is not defined for TDD systems. 

The basic multiple access scheme shall be TDM for the DL and TDMA for the UL. Optionally, a TDMA zone for the 
DL is possible in addition to the regular TDM zone. 
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8.2.1 Frame structure for downlink 

The DL frame consists of the DL frame preamble, the control zone with a variable length, the TDM zone and the 
optional TDMA zone as described in figure 17 (see also the figures in clauses 5.2.2 and 5.2.3 describing the DLC-PHY 
interface). The length of the TDM zone (in case of TDM only) or the lengths of TDM and TDMA zones (in case of 
additional TDMA) are variable. 
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Figure 17: Maps and basic DL frame structure with TDMA option 

The DL data to different ATs shall be multiplexed in the time domain (TDM). The TDM zone of the DL frame consists 
of a few TDM regions (with the same PHY mode in one region) in a robustness descending order (PHY mode #1, #2, 
etc.), where the number of regions is given by the cardinality of the PHY mode set. The control zone at the beginning of 
the DL frame shall be transmitted with the most robust PHY mode #0 to allow the reception of the control zone by all 
ATs. 

TDMA regions are optionally present on the DL. In this case, an AT (supporting TDMA) may be assigned to receive 
DL transmissions either in a TDM region as previously described or in a TDMA region. The TDMA region allocations 
shall be broadcasted as part of the DL map. The AP scheduler could use the DL TDMA feature as it increases channel 
utilization and minimizes latencies. Note that a TDMA region may serve more than one AT by time division 
multiplexing DL data to several ATs. 

A DL burst in the TDMA zone constitutes FEC blocks of a specific PHY mode, i.e. the DL burst corresponds to a PHY 
mode region plus the preamble of the PHY mode region. A DL burst can serve several ATs. Several DL bursts with the 
same PHY mode can appear. 

The DL regions shall be identified by the DIUC that indicates the PHY parameters as well as whether the region is 
preceded by a preamble (in case of TDMA) or not (in case of TDM). The UL data stream for different ATs shall be 
broken into UL bursts, where the grants to the ATs are given by the Starting Symbols (SS) together with the PHY 
modes. 
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The control zone consists of three maps: 

• The SSs of the TDM and TDMA regions within the DL frame together with the DIUCs to identify the PHY 
modes shall be broadcasted in the DL map. The ATs are implicitly identified by the CIDs in the MAC PDU 
headers. 

• The SSs of the UL bursts in the UL frame together with the UIUCs to identify the PHY modes and the TIDs to 
address the ATs shall be broadcasted in the UL map. 

• Required re-transmissions in case of ARQ shall be broadcasted in the ARQ map and identified by the SSs of 
the "original" UL frame. 

All SSs in all maps refer to symbol granularity. 

The implementation of TDMA for the DL is optional for AP and AT. Hence, for the FDD case, there are two types of 
terminals, where the interoperability shall be guaranteed: 

• FDD terminals. These ATs shall be able to transmit and receive simultaneously. They shall support TDM in 
the DL. 

• H-FDD terminals. These ATs are not able to transmit and receive simultaneously. They shall support both 
TDM and TDMA in the DL. 

The AP shall not schedule any data to FDD ATs in the TDMA zone of the DL frame. 

NOTE: The DL frame is structured to give maximum bandwidth usage by allowing TDM for efficiency while 
allowing TDMA for maximum statistical multiplexing of half-duplex terminals. Obviously, in an FDD 
system with only FDD ATs, there is no need for a TDMA portion. The same is true for an individual 
frame in which only FDD ATs are scheduled to transmit in the UL. In reality, the TDMA portion need 
only be used in the presence of H-FDD ATs and then only when they cannot be scheduled to receive 
earlier in the frame than they transmit. 



8.2.2 Frame structure for uplink 

As more than one AT is sharing the same RF channel, the AP shall employ techniques controlling the access of ATs. 
For the UL of HA systems, TDMA shall be used. After an AT has been initialized with the system, its UL bursts are 
scheduled by the AP. An AT can transmit in a contention based manner only for bandwidth requests. 

The UL frame is subdivided in: 

• One contention-based window for bandwidth requests (maybe not present in every UL frame). 

• One or several scheduled UL ranging bursts for invited ranging request messages (maybe not present in every 
UL frame). 

• One or several scheduled UL bursts for regular traffic from the AT, where: 

long bursts carrying a mixture of several MAC data PDUs and long MAC signalling PDUs (transmitted 
with one or several FEC blocks), and 

short bursts carrying one short MAC signalling PDU (transmitted with one FEC block), have to be 
distinguished (see also clause 5.2.4 for more details for the mapping on FEC blocks). 

The location of the window and the bursts within a frame shall be indicated by the grants in the UL map which shall be 
broadcasted in the DL control zone. 

The time allocated by AP for an UL ranging burst contains the EGT (where the ATs do not need to know the value of 
the EGT). The EGT shall be in the range between 10 |is and 80 |is and shall depend on the radius of the sector. 

The time scheduled for each type of UL burst shall be large enough to provision for AT transmitter ramp-up, 

see TS 101 999 [1]. The grants in the UL maps notify the location of the burst within a frame, by pointing to the symbol 

where the AT shall start transmitting the burst preamble. 
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The PHY mode used by the AT for the scheduled UL bursts shall be specified by the UL map, whereas all 
transmissions in the bandwidth contention window and for the UL ranging burst shall use PHY mode #1. The AT 
begins its transmission with a preamble with a length of 16 or 32 symbols, depending on the AP capability that shall be 
negotiated during the initialization phase. The preamble for ranging bursts is fixed to 32 symbols. 

An UL burst for an AT transmission may include more than one MAC PDU or more than one FEC block similar to the 
DL direction. MAC PDUs shall be encapsulated into RS codewords of fixed length. The last RS codeword shall be 
shortened in the case where the number of remaining MAC PDUs is less than four. As the AT finishes to transmit its 
UL burst, it ramps down its transmitter. This period of time is expected to overlap a ramp-up period of the next AT UL 
burst scheduled for transmission. 

An UL burst shall carry one the following: 

• MAC data PDUs or long MAC signalling PDUs or dummy PDUs or a mixture of these. 

• One short MAC signalling PDU. 

NOTE: An UL burst with one short MAC signalling PDU can not contain a further short MAC signalling PDU or 
a long MAC PDU. 

Figure 18 shows a general case of UL frame composed by the window and a series of scheduled bursts transmitted by 
different ATs. The order of the basic UL frame structure shown in figure 18 is just an example and it is up to the 
scheduler in the AP to decide on the order. The window and the ranging bursts are typically not to present in every 
frame. The structure of the UL frame can change from frame to frame. 
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NOTE 1 : The window and the ranging bursts are not present in all frames. 

NOTE 2: The order of window and granted burts is just an example. 

NOTE 3: Arbitrary positions in case of several granted ranging bursts are possible. 

Figure 18: Basic UL frame structure 

A contention resolution algorithm is only required for the bandwidth request contention window, see clause 9.5. The 
contention window shall be identified by the respective UIUC entry in the UL map, the start of the window shall be 
described by the corresponding SS (Starting Symbol), and the end of the window by the next SS of the UL map. 
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Note that the SSs (of the window and of all scheduled UL bursts) in the UL map do not include the AT-dependent RTD 
(otherwise the end of the window or the end of the UL burst can not be calculated since a AT does not know the RTDs 
of all other ATs). The AT shall calculate its transmit times from the SS in the UL map entries and its specific RTD, 
see clauses 8.7.1 and 8.7.2 for more details. 



8.3 Support of FDD, H-FDD and TDD in DLC layer 

As the communication channel between the AP and ATs is bi-directional, the DL and UL paths shall be established 
utilizing the spectrum resource available to the operator. Two duplex schemes are available, one is frequency-domain 
based and one is time-domain based. 

The differences between FDD and TDD as well as the H-FDD operation have impact on the DLC layer, in particular on 
the frame structure, the allocation and scheduling mechanisms. 

All modes of operations shall use the same fixed frame duration of 1 ms. 



8.3.1 FDD mode 

Frequency Division Duplex (FDD) partitions the available spectrum into a DL RF block and an UL RF block as shown 
in figure 19. An RF channel is actually a pair of RF carriers, one from the DL RF block and one form the UL RF block, 
hence DL and UL transmissions are established on separate and independent radio channels. For HA systems both DL 
and UL RF carriers are equal in size with a width of 28 MHz. 



RF DL block 



RF UL block 



-H— I- 



RF channel 
= pair of RF carriers 



Frequency 



Figure 19: FDD frequency assignment 

Within the allocated spectrum, DL and UL RF carriers are separated equally simplifying the required radio architecture. 



8.3.2 H-FDD operation 

For the FDD mode (where the RF channel consists of a pair of a DL RF carrier and an UL RF carrier), an AT can be 
limited to half-duplex operation (H-FDD), where the transmission and reception of an AT can not occur 
simultaneously). However, the AP shall be able to transmit and receive simultaneously. Figure 20 shows an example 
with one or several FDD ATs and two H-FDD ATs. 

For H-FDD ATs, the DLC layer shall schedule DL reception events and UL reception events accordingly. Furthermore, 
the AP shall reserve a guard time for the fact that the H-FDD AT can not switch immediately from transmission to 
reception and vice versa (due to power ramping). H-FDD and FDD ATs can be served on the same RF channel. As 
figure 20 shows for an example of one (or several FDD ATs) and two H-FDD ATs, an arbitrary mix and order of 
appearance is possible. 
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Apart from the specific scheduling requirements for H-FDD ATs, the H-FDD operation is an AT feature only, that 
could simplify the implementation of an H-FDD AT at the expense of reduce peak data rates. 




Figure 20: H-FDD operation 



NOTE: In addition to the burst transmission capability of each type of AT, the H-FDD operation requires also the 
burst reception capability of H-FDD ATs as well. For H-FDD ATs, the AP should not give grants while 
the DL control zone is broadcasted. 

The H-FDD operation in the AT equipment is an optional feature. However the AP shall support the operation of 
H-FDD ATs. 



8.3.3 TDD Mode 

In the Time Division Duplex (TDD) case, a single RF channel (i.e. an RF carrier, unpaired bands) is used for DL and 
UL transmission. Both the AP and AT equipment are half-duplex. 

In contrast to FDD, the TDD mode uses the same RF carrier for DL and UL communications. The DL and UL 
transmissions are established by time-sharing the radio channel where DL and UL transmission events never overlap as 
shown in figure 22. For TDD systems the channel size is 28 MHz wide as in the FDD case. 



Frame #(N-1) 



Frame #(N) 



Frame #(N+1) 



Frame #(N+2) 



Downlink 
□ Uplink 



Figure 21 : TDD frame sequence 
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Figure 22 shows the general case of variable borders frame-by-frame between DL and UL subframes (adaptive TDD). 
However, if the border is not variable frame-by-frame, then there could be advantages for the frequency planning (i.e. a 
higher frequency re-use factor could be achieved). 

Obviously, as shown in figure 22 for the TDD operational mode the TDMA portion (from the DL) shall not be 
included, since ATs shall receive in the DL subframe and transmit in the UL subframe. 




Figure 22: TDD frame structure 



The following timing issues shall be considered for the TDD operational mode. 

Gaps for switching from DL to UL (Tx/Rx) and from UL to DL (Rx/Tx) shall be used. These gaps shall be provisioned 
within a frame as the transceiver in the AT and AP requires time to switch from transmission to reception and vice 
versa. This situation is identical to the one encountered by the H-FDD AT, as in DL TDMA the scheduler recognizes 
the AT transceiver switching limitations. The only difference is that in the TDD case the gaps are "visible" in the frame 
structure. 

The duration of the gap will be identical to the gap required by the H-FDD AT. It should be noted that the gaps are not 
required to be larger than the EGT. 

Although the TDD UL may start immediately after the DL events terminate (plus the Tx/Rx gap), the scheduler may be 
instructed to start UL bursts only after an additional guard time. This is useful in the case where the operator employs 
cell cluster (set of cells where all frequencies available to the operator are used) TDD frame synchronization to mitigate 
relevant TDD interference scenarios (i.e. hub to hub). In this case some allowance for propagation delays between the 
interferer and the victim translates into a guard time within the frame - hence reducing the probability of hub to hub and 
AT to AT interference scenarios. Note that inherently all ATs implement this feature as they are instructed by the AP 
where UL events occur. 



8.4 Entries for downlink and uplink maps 

The control zone containing the DL map, the UL map and the ARQ map and some other information fields shall be 
broadcasted at the beginning of each DL frame, immediately after the frame preamble. 



8.4.1 Downlink map entries 

The DL map shall be used by the ATs to recognize PHY mode transitions. The ATs shall receive and decode all data 
they are capable of receiving (see clause 11.3 for further details) and keep or discard MAC PDUs based on the CID in 
the PDU headers. This means that the DL map contains the ordered PHY modes descriptions for group of ATs. Since 
the ATs know the least robust PHY scheme the AP will use to transmit to them, the ATs shall only listen to PHY mode 
regions that are of this or a more robust type (see clause 1 1.3.4 for more details). 
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In case of presence of the TDMA optional zone, the DL part of the map shall contain also the transitions between the 
PHY modes in the TDMA zone (i.e. the map is unique for DL both for TDM only or TDM combined with TDMA); the 
TDM and TDMA zones shall be distinguished by means of the DIUC. 

The DL map entries shall indicate the transition between the different PHY mode regions for the TDM zone and the SS 
for DL bursts in the optional TDMA zone. For each type of zone, two fields shall compose the DL map entry: 

• DIUC (4 bits): DL interval usage code that indicates the usage of a region of the DL frame; it specifies the 
PHY mode that shall be used in the relevant region. 

• Starting Symbol (SS, 15 bits): indicates where the channel symbol at which the relevant region or DL burst 
starts. 

Figure 23 summarizes the entries for the DL map. 



as in table 19 


LSB 


DIUC (4 bits) 


SS (15 bits) 



Figure 23: DL map entry format (left bit transmitted first) 



The duration of a PHY mode region is obtained as the difference between the SSs of the consecutive DL map entries. 

The last DL map entry shall be constituted by a well-known DIUC together with the SS in order to calculate the length 
of the last PHY mode region. 

The coding of the DIUCs is reported in table 21. 



Table 21: DIUC coding 



DIUC 


Description 


0000 


Region with PHY mode #1 of PHY mode set for TDM 


0001 


Region with PHY mode #2 of PHY mode set for TDM 


0010 


Region with PHY mode #3 of PHY mode set for TDM 


0011 


Region with PHY mode #4 of PHY mode set for TDM 


0100 


Reserved 


0101 


Reserved 


0110 


Burst with mode #1 of PHY mode set for TDMA 


0111 


Burst with mode #2 of PHY mode set for TDMA 


1000 


Burst with mode #3 of PHY mode set for TDMA 


1001 


Burst with mode #4 of PHY mode set for TDMA 


1010 


Reserved 


1011 


Reserved 


1100 


Reserved 


1101 


Reserved 


1110 


Reserved 


1111 


End of map 



All relevant parameters for the PHY mode sets (i.e. C/(N + I) thresholds for DL and AT transmit power gaps for UL) 
shall be described in the PSD (PHY mode Set Descriptor), together with a PSDI (PSD indicator). The control zone 
contains the PSDI and the GBI message contains the PSD. Hence, new PHY mode sets could be specified for future 
extensions of HA. 

A change from one PHY mode set to another PHY mode set shall be communicated by the corresponding PSDI in the 
control zone. This requires only that the new PHY mode set is specified in advance by the PSD (see clause 11.4 for the 
detailed description). 

For the TDM zone, there are at most 4 DL map entries required (excluding the end-of-map entry), i.e. a DL map entry 
corresponds to a PHY mode region. 

The duration of a PHY mode region is obtained as difference between the SS of the relevant region and the SS of the 
following region. From the duration and the PHY mode of the region, the ATs can calculate the number of FEC blocks 
and PDU if necessary. The same applies for the DL bursts in the DL TDMA zone. 
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8.4.2 Uplink map entries 

The UL map shall be used by the ATs to recognize when they shall start and stop the transmission of their bursts. The 
UL map contains the PHY mode descriptions together with the TIDs and the SSs. For each granted UL burst three fields 
shall compose the UL map entry: 

• UIUC (4 bits): UL interval usage code that indicates the usage of an UL burst; it specifies the PHY mode that 
shall be used in the relevant burst; 

• TID (10 bits): terminal identity of the terminal that shall transmit in the relevant UL burst; 

• Starting Symbol (SS, 15 bits): indicates where the channel symbol at which the relevant burst starts (first 
symbol of the burst preamble). 

This is shown in figure 24. 



as in table 20 


LSB 


LSB 


UIUC (4 bits) 


TID (10 bits) 


SS (15 bits) 



Figure 24: UL map entry format (left bit transmitted first) 



The last UL map entry shall be constituted by a well-known UIUC together with the SS field (and a specific "end" TID, 
see clause 6.4.2); it states the end of the UL part of the map. The duration of a burst is obtained as difference between 
the SS of the relevant burst and the SS of the following burst. 

The coding of the UIUC is reported in table 22. 



Table 22: UIUC coding 



UIUC 


Description 


0000 


Burst with mode #1 of PHY mode set for data/long MAC PDU 


0001 


Burst with mode #2 of PHY mode set for data/long MAC PDU 


0010 


Burst with mode #3 of PHY mode set for data/long MAC PDU 


0011 


Burst with mode #1 of PHY mode set for short MAC signalling PDU 


0100 


Burst with mode #2 of PHY mode set for short MAC signalling PDU 


0101 


Burst with mode #3 of PHY mode set for short MAC signalling PDU 


0110 


Bandwidth request contention window with mode #1 


0111 


Invited ranging burst with mode #1 


1000 


Reserved 


1001 


Reserved 


1010 


Reserved 


1011 


Reserved 


1100 


Reserved 


1101 


Reserved 


1110 


Reserved 


1111 


End of map 



The first three UIUC codes in table 22 refer to the long MAC PDUs. 

The following rules shall be applied concerning the use of the Turbo code option: 

• Depending on the result of the PHY capabilities negotiation during initialization, the AT shall use PTC 
(Product Turbo Code) in the first three UIUC entries (i.e. for long PDUs) if applicable, but not for the short 
PDUs. 

• Unless the PHY capabilities process is not completely finished, PTC shall not be used. 

For the contention window, only one entry per window is required in the UL map (if the window is present). Since the 
contention window is not AT-specific, a specific TID field ("broadcast TID") shall be used for the contention window 
(see clause 6.3.2), so the distinction between PDUs transmitted in the contention window and invited MAC PDUs is 
made by the TID as well as by the position within the frame. The PHY mode for the contention windows shall always 
be mode #1, since this enhances the robustness of the contention detection algorithm (even if longer UL bursts increase 
the probability of contentions). 
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Similarly, for the granted UL ranging burst, the PHY mode shall be again always mode #1, since this enhances the 
robustness of the measurements at the AP to gain the power and timing corrections for the ranging response message. 
Note that each UL ranging burst requires its own entry in the UL map (since TID is required for the entry). 

For the granted short MAC signalling PDUs, all PHY modes are possible. However, an UL burst for a granted short 
MAC signalling PDU shall only contain this short PDU and nothing more, i.e. each short MAC signalling PDU requires 
an extra entry for the UL map. Note that it is not excluded (but it makes no sense) to grant more than one short MAC 
signalling PDU to an AT (since otherwise one long MAC signalling PDU is more efficient but not longer than two short 
MAC signalling PDUs). 

8.5 Automatic Repeat Request (ARQ) 

8.5.1 Operational conditions for ARQ 

The support of ARQ with up to two re-transmissions is mandatory for all ATs. An AT can have simultaneously 
connections with ARQ on and connections with ARQ off, i.e. ARQ can be switched on/off on a per connection basis 
and is negotiated during the connection set-up or connection change procedure. 

The application of ARQ is optional for the AP. The maximum number of re-transmissions can be limited to (i.e. no 
ARQ) or 1 or 2 by the AP. ARQ shall not be applied to any RLC signalling, i.e. ARQ is not applied to the MAC 
management connections. 

8.5.2 Frame structure for ARQ 

The ARQ protocol organizing re-transmissions for corrupted received MAC PDUs is performed in the DLC layer and 
the error detection for ARQ is provided by the PHY layer. The ARQ mechanism shall be based on a selective-repeat 
approach, where only the MAC PDUs carried by erroneously received RS codewords shall be re-transmitted. 

In the AP, the received RS codewords are checked and in case of detected errors the RS codeword itself and all MAC 
PDUs carried by this codeword shall be discarded. If at least one erroneous RS codeword in the UL frame #N is 
detected (and if the grant for this burst was scheduled to an AT that has at least one ARQ-enabled connection), then the 
AP shall set an indication in the ARQ map of the control zone of the DL frame #(N + 2). This indication shall enforce 
the AT to re-transmit in the UL frame #(N + 2) all MAC PDUs for ARQ-enabled connections contained in the 
erroneous RS codeword. MAC PDUs for non- ARQ-enabled connections shall not be re-transmitted. 

The indication in the ARQ map shall be signalled by an ARQ_ACK field of 1 bit, where ARQ_ACK = for the first 
field in the ARQ map means no re-transmissions. The number of ARQ entries depends on the number of erroneously 
detected RS codewords. 
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An example is shown in figure 25 (note that this figure shows the transmission of the UL frame at the AT, whereas the 
figures in clause 8.7 show the reception of the UL frame at the AP). 
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Figure 25: Relation between DL and UL frames for ARQ 



NOTE: The re-transmission scheme shall have an RS codeword-based granularity, i.e. not a PDU-based 
granularity. However, this difference disappears with the option of only one MAC PDU per RS 
codeword. 



8.5.3 ARQ map entries 

The entries in the ARQ map shall be composed of the following three fields: 

• Starting Symbol (SS, 15 bits); 

• ARQ_CW_NUM is the number of consecutive RS codewords to be re-transmitted for the same AT (2 bits, 
hence indicating up to another four RS codewords, where ARQ_CW_NUM = means one RS codeword); 

• ARQ_ACK (1 bit) shall indicate whether the ARQ map is terminated (ARQ_ACK = 0) or further ARQ entries 
are following (ARQ_ACK =1). 

The entries for the ARQ map are shown in figure 26. One ARQ map entry addresses only one AT but not several ATs. 



LSB 


LSB 




F SS (15 bits) 


ARQ_CW_NUM (2 bits) 


ARQ ACK (1 bit) 



Figure 26: ARQ map entry format (left bit transmitted first) 



If there are more than four consecutive corrupted RS codewords from the same AT or if there are corrupted RS 
codewords with at least one non-interrupted RS codeword in between, then this will cause several entries in the ARQ 
map for this single AT. 

The ARQ re-transmission mechanism is based on the SSs of the RS codewords (or FEC blocks) in the concerned UL 
frame. 
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The ATs shall keep in memory all the ARQ-enabled MAC PDUs sent and their exact positioning in frame #N, till the 
ARQ map for frame #(N + 2) is received. This shall be extended till frame #(N + 4) if a second re-transmission is 
possible. In case of a second re-transmission, the ARQ map in frame #(N + 4) contains the appropriate SS of UL frame 
#(N + 2), i.e. not of UL frame #N. 

On the AP side, all received MAC PDUs for which ARQ is enabled shall be kept in the AP memory until all previously 
received MAC PDUs are positively acknowledged in frame #(N + 2) or #(N + 4), in order to preserve the order of the 
MAC PDU sequence. 



8.5.4 Rules for re-transmissions 

The following rules shall be applied: 

• Re-transmitted MAC PDUs and "new" MAC PDUs can be transmitted within the same RS codeword. 

• The grants for an AT are for the combination of "old" RS codewords to be re-transmitted and the "new" MAC 
PDUs (if applicable) where re-transmitted RS codewords shall be transmitted first. 

• If an AT is given a re-transmission grant for an RS codeword that partly or completely contains MAC PDUs 
belonging to non-ARQ connections, then the AT shall either replace non-ARQ MAC PDUs by MAC dummy 
PDUs or by "new" MAC PDUs for non-ARQ enabled connections. 

• The grant given to an AT (by the UL map) shall be large enough to accommodate all re-transmissions as 
requested (by the ARQ map). 

NOTE: Re-transmission of RS codewords means exactly, that the MAC PDUs of the old RS codeword are again 
grouped together to form the new RS codeword, where the individual new encryption of each MAC PDU 
is different to the old encryption due to the dependence on the frame counter. Hence the ciphertext 
subjected to the RS encoder is not the same for a re-transmission. Moreover, non-ARQ enabled MAC 
PDUs can be replaced by MAC dummy PDUs or new MAC PDUs for the respective RS codeword, 
see above. 



Figure 27 shows an example for the re-transmission of MAC PDUs. 



The AT has a grant for 6 PDUs and transmits two FEC blocks as follows in frame #N: 



p 


1 A 


2A 
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4 | PC | 
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6A 


PC 




SS2 





Both FEC blocks are received in AP with errors... 

• the ARQ map contains the entries (SS = SS2, CW_NUM = 2, ARQ_END),... 

• the UL map contains the entries (UIUC,TID = 1,SS = SSS), (UIUC ,TID=x,SS = SS9),... 

(Note: SS9-SS5 must be calculated in AP so that no spectrum is wasted) 



The AT has many other PDUs (7, 8, 9,...) to transmit, but receives a grant for only 8 PDUs in frame #(N+2) 
First possibility for the AT (dummy PDUs to replace old non-ARQ enabled PDUs) 
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Legend: 1,2,3,... enumerates all PDUs of an AT (TID = 1), 

A = ARQ-enabled connection, D = dummy PDU, G = guard time, P = preamble, PC = parity checks, 
solid line = border between RS C Ws, dashed line = border between PDUs in an RS CW 



Figure 27: ARQ re-transmission example 
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8.5.5 Impact of ARQ on delay and overhead (informal) 

The impact of ARQ in terms of delay and spectrum efficiency is as follows: 

• In terms of delay, the support of an ARQ feature in the UL direction implies: 

The introduction of a fixed delay for all data to be retransmitted from the AT to the AP, depending on the 
maximum number of re-transmissions (selected by AP). So ARQ is only applicable for those connections 
for which this additional delay is tolerable. 

Additional CDV can be avoided by appropriate implementations. 

For connections without ARQ it is not necessary to send the MAC PDUs (identified by CID) through the 
ARQ buffers to avoid any additional delay. 

• In terms of spectrum efficiency, the support for ARQ feature implies: 

One additional bit of fixed overhead in the control zone of the DL (if there is no ARQ this is the only 
overhead due to ARQ). 

An additional ARQ map in the control zone where the length depends on the number of PDUs to be 
re-transmitted. 

Additional re-transmissions in the UL. 

Wasted grants for non-ARQ enabled connections. 

8.6 Structure of the control zone 
8.6.1 Overview of main fields 

The control zone shall be broadcasted at the beginning of each DL frame immediately after the frame preamble and its 
general structure is reported in figure 28. 



Description 


Length [bit] 


Broadcast Frame Information 

(Length, frame counter, APC-ID, PSDI, map version number) 


60 


DL map entries for TDM 

(DIUC, SS) 


typically 4x19 
(without EndOfMap) 


DL map entries for TDMA (optional) 

(DIUC, SS) 


variable x 19 


ARQ map entries (optional) 

(SS, ARQ_CW_NUM, ARQ ACK) 


variable, > 1 


UL map entries for windows 

(UIUC, TID, SS) 


variable x 29 


UL map entries 

(UIUC, TID, SS) 


variable x 29 


Padding till end of short RS block 


variable, < 239 



Figure 28: General structure of the control zone 
(not all details shown) 
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The following fields shall compose the control zone: 

• Broadcast Frame Information (60 bits), consisting of: 

Length of the control zone in FEC blocks (4 bits); 

Frame counter used for the IV generation for encryption (24 bits); 

APC-ID (24 bits); 

PSDI (4 bits); 

Map version number (4 bits, shall be set to all-zero in AP and shall be ignored by all ATs). 

• Entries for DL map for TDM and TDMA zones, indicating the transitions between PHY modes, consisting of: 

DIUC (4 bits) to indicate the type of PHY mode region or DL burst; 

SS (15 bits) to indicate the channel symbol the relevant region (or DL burst, for TDMA) shall start from. 

• Entries for ARQ map, consisting of: 

ARQ_ACK (1 bit) to indicate whether the ARQ map consists of this bit only (ARQ_ACK = 0, i.e. no 
re-transmissions) or further entries will follow (ARQ_ACK = 1, i.e. re-transmissions are specified by 
subsequent ARQ map entries); 

SS (15 bits) to reference to the RS codewords from the previous frame; 

ARQ_CW_NUM is the number of consecutive RS codewords to be re-transmitted for the same AT (2 
bits, hence indicating up to another three RS codewords); 

ARQ_ACK (1 bit) shall indicate whether the ARQ map is terminated (ARQ_ACK = 0) or further ARQ 
entries are following (ARQ_ACK = 1). 

• Entries for UL map, indicating when the ATs shall transmit their bursts, consisting of: 

UIUC (4 bits) to indicate the PHY mode the that shall be used in the relevant burst or to indicate a 
contention window or to indicate a request and grant for the MTL PDU; 

TID (10 bits) to identify the terminal that shall transmit in the relevant burst; 

SS (15 bits) to indicate the channel symbol the relevant burst shall start from. 

• Padding bits to avoid any shortening of the short RS codewords used for the protection of the control zone 
(less than 30 padding bytes). 

The length of the control zone is variable, but shall be at least three short map FEC blocks (and so three short RS 
codewords, see clause 8.6.3) and shall always be an integer multiple of the FEC length. The short RS codewords are not 
shortened. 

NOTE: If less than four PHY mode regions are present, then it is allowed to repeat the EndOfMap entry in the DL 
map so to have always 5 entries for the DL map (if no TDMA zone is present). 
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8.6.2 Further details of all fields 

A more detailed representation of the control zone is reported in figure 29. 



Description 


Length [bits] 


Length of control zone (number of FEC blocks) 


4 


Frame counter 


24 


APC-ID 


24 


PSDI 


4 


Map version number 


4 


DL map entry (DIUC, SS) 


4 + 15 


DL map entry (DIUC, SS) 


4 + 15 


variable number of repetitions 




DL map entry (DIUC, SS) 


4 + 15 


end of DL map (DIUC = 1111, SS) 


4 + 15 


ARQACK 


1 


ARQ map entry (SS, CW_NUM, ARQ ACK = 1) 


15 + 2 + 1 


ARQ map entry (SS, CW_NUM, ARQ ACK = 1) 


15 + 2+1 


variable number of repetitions 




A n /"~"\ . / O O /~H ft / KM II I A n /~\ A 1/ -4 \ 

ARQ map entry (SS, CW NUM, ARQ ACK = 1) 


15 + 2+1 


ARQ map entry (SS, CW_NUM, ARQ ACK = 0) 


15 + 2+1 


UL map entry for window (UIUC, TID, SS) 


4+10 + 15 


variable number of repetitions 




UL map entry for window (UIUC, TID, SS) 


4+10 + 15 


UL map entry for grant (UIUC, TID, SS) 


4+10 + 15 


UL map entry for grant (UIUC, TID, SS) 


4+10 + 15 


variable number of repetitions 




UL map entry for grant (UIUC, TID, SS) 


4+10 + 15 


end of UL map for grant (UIUC = 1111, TID, SS) 


4 + 10+15 


Padding till end of short RS block 


variable 



Figure 29: Control zone details 
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Map version number 



DL map entry 
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ARQ map entry (18bit) 
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padding 



Figure 30: Bit structure of control zone (left bit transmitted first) 

Some additional background information: 

• The DIUC positions are fixed, so DIUC =1111 and ARQ_ACK are clearly detected in the AT receiver. The 
SS (means first symbol after last DL entry) together with DIUC = 1 1 1 1 is included to allow the calculation of 
the length of the last PHY mode region (or DL burst in case of TDM A). 

• The further ARQ_ACK positions are fixed, so the end of the ARQ map is clearly detected in the AT receiver. 

• The first UIUC position is clearly detected and the further UIUC positions are fixed. The SS (means first 
symbol after last UL entry) together with UIUC = 1 1 1 1 is included to allow the calculation of the length of the 
last UL burst. 

• In case of TDD mode, the end of the DL subframe and the start of the UL subframe are also clear from the 
control zone. 

8.6.3 FEC scheme for fast decoding 

The control zone shall be broadcasted at the beginning of each DL frame with PHY mode #0. Since this information is 
the most important one, it is strongly protected with a very robust PHY mode: 

• outer shortened RS(46,30,t = 8) code (i.e. same type as for traffic data, only different shortening); 

• inner convolutional code of rate 1/2 (i.e. this is not a PHY mode out of the regular PHY mode set) without 
puncturing; 

• QPSK modulation. 
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1 ms fixed frame duration 




QPSK and concatenated encoded CCl/2+RS(46,30,t=8) 
and 6 tailbits per each RS codeword 



/ fixed length ~ ^ fixed length 



fixed length 



RS codeword 



RS codeword 



30 bytes 
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-X- 



Broadcast DL map ARQ map 
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fixed length variable length variable length 
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UL map 
variable length 



\ ^ 30-k padding bytes 
N k bytes 



Figure 31 : FEC protection of the control zone 



The coding procedure for protecting the control zone is illustrated in figure 3 1 . The map byte sequence shall be 
segmented into segments of 30 bytes. Each of these 30 bytes shall be encoded with the outer RS code. The remaining 
k bytes if less than 30 bytes shall be padded with dummy bytes in order to have a constant length codeword, 
i.e. 30 bytes before RS coding. 



8.7 Time Relevance of Starting Symbols (SS) and maps 

This clause and the next clause describe issues related to the interface between DLC and PHY layers. 

In this clause, firstly, the time relevance of the Starting Symbols (SS) and the computation of the actual transmit times 
for scheduled UL bursts is covered. Secondly, the time relevance of maps, or in other words the influence of the Frame 
Offset (FO) is presented, especially for the UL map since the timing for the DL map is trivial. 



8.7.1 Starting Symbols for UL bursts 

The AT knows: 

• The sector-specific Frame Offset (FO) from reading the GBI message; and 

• its individual Transmission Delay (TD) or the Round Trip Delay (RTD) from the initialization phase (and 
updated by further AT-specific messages in the DL if required). 

• The RTD is simply the double of TD and EGT shall be equal or larger than the maximum of RTD (determined 
by the farthest AT in the sector). 

• The FO is chosen by the AP, however, usually the FO should be larger than the sum of the maximum length of 
the control zone plus the EGT plus the TP (Time for Processing), where TP denotes the time required in the 
AT to decode the UL map after complete reception of the control zone. 
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The calculation of the physical starting time (derived from the numbering of the received DL frame) for an UL burst 
from the Starting Symbol (SS) contained in the UL map entries is shown in figure 32. 



DL frame 
transmitted 
at AP 



UL frame 
received 
at AP 



DL frame 
received 
at ATI 



UL burst 
transmitted 
at ATI within 
UL frame 



frame duration 





control 
zone 


EGT TP 




■* ► 


4 ►j4-> 


UL map: 
SS ATI, 
SS~AT2,... 















4 — 










frame duration 




4 


FO 




► 




SS. 


ATI 


SS. 


AT2 




► 












UL burst 
from ATI 






control 
zone 


TP 






Tla 


Tib 




where 






■4 ► 


4 ► 














Tla=FO-RTD+SS 


ATI 




UL map: 
SS ATI, 
SS_AT2,... 












Tlb=FO-RTD+SS. 


~AT2 



TD 



FO-RTD 



TD 



TD 



UL burst 
from ATI 



Figure 32: Starting times for UL bursts 



In figure 32, the terminal ATI is assumed at the maximum distance from the AP for simplicity, so EGT = RTD. The UL 
map contains an entry for ATI with the starting symbol SS_AT1. The next entry in the UL map contains a starting 
symbol SS_AT2 for another terminal AT2. The SS values refer to the numbering of the UL frame at the AP, where the 
range is determined by < SS < 22 399 (note that the symbol rate is 22,4 MBaud and the frame duration is 1 ms). 

The ATI counts the symbols in the received DL frame, from 1 to 22 400. With regard to this counter, ATI is allowed to 
transmit from Tla = FO-RTD + SS_AT1 till Tib = FO-RTD + SS_AT2. 

NOTE 1: This follows from the specific case of SS_AT1 = (which is immediately intelligible). 

NOTE 2: It is not possible to incorporate the specific RTD in the UL grant SS_AT1, since the ATI need to know 
RTD for AT2 to calculate Tib, and so ATI could not calculate the number of granted PDUs. In other 
words, the granted SSs of the UL map are under the assumption of RTD = and each AT has to compute 
Tla and Tib from SS and its own RTD. 
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8.7.2 Time relevance of maps for FDD mode 

In the FDD operational mode, the DL map shall pertain to the current frame (protected by at least two short RS 
codewords to allow for a processing time for the decoding of the first DL map entries whilst the rest of the control zone 
is still on air). The time relevance of UL maps may be as follows (with respect to the reception at the AP): 

• Minimum time relevance: The UL frame starts as soon as possible, i.e. the Frame Offset (FO) attains the 
minimum value of 2/5 of a frame (0,4 ms) to provide for the maximum Round Trip Delay (RTD) plus the 
required Time for Processing (TP) in the AT to decode the UL map (see figure 33) and to encode the UL burst. 
This choice is determined by the maximum length of the control zone under worst-case conditions plus RTD 
plus TP. This was also the assumption in figure 32. 

• Maximum time relevance: The UL frame starts late at the following frame (see figure 34). The FO is 
identical to the frame duration. 

• Other time relevance: The UL frame starts something in between minimum and maximum time relevance. 

The computation of the transmit time Ta in clause 8.7.1 for scheduled UL bursts and in clause 8.7.2 is valid for all of 
the scenarios listed above. 

The minimum time relevance of the UL map is shown in figure 33. 
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Figure 33: Minimum time relevance for UL map (FDD mode) 
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The maximum time relevance of the UL map is shown in figure 34. 




Figure 34: Maximum time relevance for UL map (FDD mode) 



8.7.3 Time relevance of maps for TDD mode 

In the TDD operational mode, the UL map may pertain to the UL frame of either the current frame (minimum time 
relevance, see figure 35) or the next frame (see figure 36). 

For a fixed partition of the frame into DL and UL subframes, the handling of the Frame Offset (FO) can be exactly 
identical to that for the FDD mode. However, even for an adaptive TDD split (ATDD), the computation of the transmit 
times can be done as presented in clauses 8.7. 1 and 8.7.2, where the FO is set to zero and the UL map entries refer 
directly to the SS of the UL subframe. The UL map entries depend also on the minimum or maximum time relevance. 

The minimum time relevance of the UL map is shown in figure 35. In case of adaptive TDD, the lengths of the DL and 
UL subframes can be variable over time, however, the length of the DL subframe shall be at least the Extended Guard 
Time (EGT) plus the Time for Processing (TP). 
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Figure 35: Minimum time relevance for UL map (TDD mode) 
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The maximum time relevance of the UL map is shown in figure 36: 

frame duration frame duration 

^ - — 

DL 

control 
zone 
at AP 



frame duration 



DL 

subframe 
at AP 



UL 

subframe 
at AP 




Figure 36: Maximum time relevance for UL map (TDD mode) 



8.7.4 Timing rule for some specific short grants 

There are a few situations where the AP sends a message in the DL and gives a grant for a short MAC PDU that shall be 
used with a specific UL message: 

• The message RlcRangingContinue is sent in DL, the next grant for an UL ranging burst shall be used to 
transmit the message RlcRangingReq. 

• The message RlcRangingSuccess is sent in DL, the next grant for an UL ranging burst shall be used to 
transmit the message RlcRangingAck. 

• The message RlcQueueStatusReq is sent in DL, the next grant for a short MAC PDU shall be used to 
transmit the message RlcQueueStatusRsp. 

• The message RlcUplinkCorrection is sent in DL with the parameter MeasurementReportReq=l, 
the next grant for a short MAC PDU shall be used to transmit the message 

RlcMeasurement Report Data. 

For all these cases, the following timing rule shall be applied: If the DL message is transmitted in frame #N, then the 
grant for the short burst (i.e. short MAC PDU or UL ranging burst) shall be given as follows: 

• For RlcRangingContinue messages: At frame N+10 or later. 

• For RlcRangingSuccess messages: At frame N+10 or later. 

• For RlcQueueStatusReq messages: At frame N+l or later. 

• For RlcUplinkCorrection messages: At frame N+4 or later. 
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8.8 General Broadcast Information (GBI) message 

The GBI (General Broadcast Information) message RlcGeneralBroadcastlnf ormation is a broadcast message 
containing general carrier-specific information that does not need to be transmitted in each frame (in contrast to the 
broadcast information contained in the control zone of each DL frame). The content of the GBI message can be grouped 
into several parts: 

• General information about the carrier (and the network) related to operation modes, frame offset, message 
periods, structure of UL bursts, parameters for contention resolution and some other information fields. 

• The PSD (PHY mode Set Descriptor) containing the C/(N + I) thresholds for all relevant sets of PHY modes 
(currently up to two) together with a PSD-specific PSDI (PSD Indicator). The PSDI is just a reference to the 
PSD. The description of the PHY mode includes the thresholds for up (channel improves) and down (channel 
is worse off) direction together with the respective changes of the transmit power that shall be applied during 
PHY mode switching. 

Normally, only one set shall be described by the PSD. However, if a change from one PHY mode set to another PHY 
mode set shall be performed, then the new set shall be described by the PSD some time in advance, where a strict period 
is not required. The GBI message with the new PSD shall be broadcasted several times to guarantee that almost all ATs 
have received the information correctly. 

The parameters carried in the PSD part are described in figure 37: 

• 2n C/N thresholds (each threshold requires 8 bit prior to encoding); and 

• 4(m-l) transmit power gaps (each gap requires 6 bit prior to encoding); 

• shall be transmitted for one PHY mode set, where n and m are the numbers of PHY modes for DL and UL 
direction, respectively. 



C/(N+I) for DL 



PHY mode 4 = n 



PHY mode 3 



PHY mode 2 



PHY mode 1 



Perform 
DL ATPC 
(optional) 



Radio link quality 



TX power for UL TX power for UL 
(non-TC mode) (TC mode) 



PHY mode 3 = m 



increase 
decrease 



Upgrade 



PHY mode 2 



^ PHY mode 1 
Downgrade 



2n 

thresholds 



2(m-l) 
TX power corrections 



2(m-l) 
TX power corrections 



Figure 37: Parameters for PHY mode set description 

The dynamic use of the C/(N + I) threshold pairs is specified in clause 1 1.3.4. The first (lower values) C/(N + I) 
threshold pair is only relevant if the optional DL ATPC is activated (see clause 1 1 .3.6) but shall be always contained in 
the GBI message. The transmit power gaps for PTC are only relevant if at least one AT in the carrier uses the PTC 
option, but again these values shall be always contained in the GBI message. 
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The complete GBI message is described in table 23. Note that normally only one PHY mode set is present, and two 
PHY mode sets are only present during the PHY mode set exchange phase (even in this case, the GBI message fits into 
one long MAC signalling PDU). 



Table 23: GBI message (update, fixVar) 



RlcGeneralBroadca st Information 



SEQUENCE { 



— broadcast 



duplexMode 


DuplexMode, 




1 


bit 


f rameOf f set 


FrameOf f set, 




5 


bit 


tdmaZoneDownlink 


TdmaZoneDownlink, 




1 


bit 


encrypt ionMode 


Encrypt ionMode, 




1 


bit 


uplinkPower IncRangingStart 


UplinkPower IncRangingStart , 




3 


bit 


uplinkPowerMaxRangingStart 


UplinkPowerMax, 




4 


bit 


downlinkPowerControl 


DownlinkPowerControl, 




1 


bit 


periodMeasurementReportGBI 


PeriodMeasurementReportGBI , 




3 


bit 


periodRanginglnvitat ion 


PeriodRanginglnvitat ion, 




8 


bit 


timerGranuConnection 


TimerGranuConnection, 




8 


bit 


timerGranuSecurity 


TimerGranuSecurity, 




6 


bit 


uplinkNumberPduPerFecBlock 


UplinkNumberPduPerFecBlock, 




1 


bit 


uplinkNumberMidamblePerBurst 


UplinkNumberMidamblePerBurst , 




1 


bit 


crMaxNumberRet ries 


CrMaxNumberRet ries, 




4 


bit 


crStartingWindowSize 


CrStartingWindowSize, 




3 


bit 


crMaxBackoff Window 


CrMaxBackoff Window, 




6 


bit 


f ixedVariableChannellnd 


F ixedVariableChannellnd, 




1 


bit 


phyMode Set Descriptor Cur rent 


PhyModeSetDe script or, 




variable 


phyModeSetDescriptorFuture 


PhyModeSetDescriptor OPTIONAL 




variable 



} 

DuplexMode 
fdd 
tdd 

} 

TdmaZoneDownlink 
present 
notPresent 



:= ENUMERATED { 

(0) , 

(1) 



:= ENUMERATED { 

(0) , 

(1) 



DownlinkPowerControl ::= ENUMERATED { 
downlinkPowerControlNo (0), 
downlinkPowerControlYes (1) 

} 



ignore PhyThresholdsList ( ) 



Encrypt ionMode 

encrypt ionOn 
encrypt ionOf f 

} 

FrameOf f set 



PeriodRanginglnvitat ion 



:= ENUMERATED { 
(0) , 

(1) 



INTEGER ( 8 . .16) — 5 bit, granu=0 . 05ms, range= [0 . 4, 1 ] ms 

INTEGER (0 .. 255) — 8 bit, granu=1000f rame 
— means no invitations 



PeriodMeasurementReportGBI ::= PeriodMeasurementReport 
(period050. . noPeriodicReport s ) 

PeriodMeasurementReport ::= INTEGER { 

usePeriodicMeasurementReportGBI (0) , 

only for periodMeasurementReportAtSpecif ic in RlcMeasurementReportCriterium, 
but not for 

periodMeasurementReportGBI in RlcGeneralBroadcast Inf ormation 

period050 (1) , — 50 ms 

periodlOO (2) , — 100 ms 

periodl50 (3), — 150 ms 

period200 (4) , — 200 ms 

noPeriodicReports (5) 



TimerGranuConnection 



INTEGER ( 8 . .255) 



bit, granu=lframe 
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TimerGranuSecurity 



INTEGER (1 .. 63) — 6 bit, granu=128f rame 



UplinkNumberPduPerFecBlock ::= ENUMERATED { 

onePduPerFecBlock (0), 

severalPerFecBlock (1) 

} 

UplinkNumberMidamblePerBurst ::= ENUMERATED { 

oneMidamblePerBur st (0), 

severalMidamblePerBur st (1) 



CrMaxNumberRetries 
CrStartingWindowSize 
CrMaxBackoff Window 



INTEGER (0 . .15) — 4 bit 
INTEGER (0 . .7) — 3 bit 
INTEGER (0 . .63) — 6 bit 



FixedVariableChannellnd 
fixedChannel (0), 
variableChannel (1) 



:= ENUMERATED { 

shall be used 
not allowed 



PhyModeSet Descriptor 



SEQUENCE { 



psdi 

downlinkPhyThresholdsList 

uplinkPowerModChangeListNonTc 

uplinkPowerModChangeListTc 



Psdi, 

PhyThresholdsList , 
UplinkPowerModChangeList , 
UplinkPowerModChangeList 



— 4 bit 

— variable 

— variable 

— variable 



Psdi 



INTEGER {phyModeSetl (1), phyModeSet2 (2)} (0..15) 



4 bit 



PhyThresholdsList ::= SEQUENCE (SIZE (2.. 7)) OF PhyThresholdPair 

— allows 2. .7 PHY modes per set, 2*8 bit per pair, see RRC 

— 1st pair for DL ATPC, to be ignored if no DL ATPC 

2nd pair for model /mode2 , 3rd pair for mode2/mode3, etc. 

UplinkPowerModChangeList ::= SEQUENCE (SIZE (1.. 6)) OF UplinkPowerModChangePair 

— allows 2.. 7 PHY modes per set, 6 bit per entry, see common 
TX power steps for UL PHY change 

— 1st gap pair for model/mode2, 

2nd gap pair for mode2/mode3, etc. 



UplinkPowerModChangePair ::= SEQUENCE { 

upPowerModChange UplinkPowerModChange, 
downPowerModChange UplinkPowerModChange 

} 



channel quality increase 
channel quality decrease 



PhyThresholdPair 
upThreshold 
downThreshold 

} 



: : = SEQUENCE { 
CnrThreshold, 
CnrThreshold 



channel quality increase 
channel quality decrease 



PhyThresholdPair 
upThreshold 
downThreshold 

} 



: := SEQUENCE { 
CnrThreshold, 
CnrThreshold 



channel quality increase 
channel quality decrease 



CnrThreshold 



INTEGER (0 .. 255) — 8 bit , granu=0 . 2 5dB, range= [ 4 , 4 ] dB, absolute 



UplinkPowerlncRangingStart 

UplinkPowerModChange 

UplinkPowerMax 



= INTEGER ( . . 7 ) — 3 bit , granu=l . OdB, range= [ +1, +8]dB 
= INTEGER (0 .. 32) — 6 bit , granu=0 . 5dB, range= [ -8, +8]dB 
= INTEGER (10. .20) — 4 bit , granu=l . OdB, range= [ +10 , +20 ] dBm 



The parameter FixedVariableChannellnd shall be set to the value fixedChannel and the ATs shall ignore 
this parameter. 
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A change of PHY modes is performed as follows: 

• A change from one to another PHY mode for a specific AT is part of the regular adaptive operation in DL and 
UL and is communicated by the DIUC and UIUC, respectively. 

• A change from one to another PHY mode set for a sector is communicated by the corresponding PSDI in the 
control zone. 

More details are specified in clause 1 1 .4. Some rules for the PHY mode sets: 

• PHY mode #1 is identical for all PHY mode sets. The PHY mode sets are listed in table 24. 



Table 24: PHY mode sets 



Mode# 


Set 1 (mandatory for AP and AT) 
PSDI = 1 


Set 2 (optional for AP) 
PSDI = 2 





QPSK + RS(t 
(only for control zone, inde 


= 8) + CC1/2 

pendent of PHY mode set) 


1 


QPSK + RS(t = 8) + CC2/3 


QPSK + RS(t = 8) + CC2/3 


2 


QPSK + RS(t = 8) 


QPSK + RS(t = 8) 


3 


1 6 - QAM + RS(t = 8) + CC7/8 


16- QAM + RS(t = 8) 


4 


64 - QAM + RS(t = 8) + CC5/6 


64 - QAM + RS(t = 8) 



• The DL PHY mode set consists of 4 modes (where the highest mode is optional). 

• The UL PHY mode set consists of 3 modes (where the highest mode is optional per AT). 

• The PHY mode set in use should be always the same for all carriers of a sector. 

NOTE: The fact that the UL PHY mode is a subset of the DL PHY modes (without the PTC option) has no 
impact on the DLC layer. 

8.9 AT reaction to undefined parameters 

For the reception in the DL of undefined values of parameters the AT shall ignore this message. For undefined 
parameters in the control zone, the complete control zone shall be ignored, i.e. the AT does not transmit in the UL 
frame. 



9 Resource-Grant Control (RGC) and contention 
resolution 

9.1 General 

While the downlink data stream will be a continuous sequence of frames broadcasted to all ATs, the uplink will be a 
discontinuous burst point-to-point transmission from each AT to the AP. 

The Medium Access Control (MAC) protocol is a central feature of a PMP system. The function of the MAC sublayer 
in a shared-medium network is to deal with the fact that the physical medium is shared. All ATs cannot transmit at the 
same time successfully, as they could in a dedicated-medium situation such as pertains with a switch and point-to-point 
wiring. The MAC layer determines who transmits when, and if contention is allowed, the MAC controls the contention 
process and resolves any collisions that occur. 

Each burst in the uplink is reserved to transmissions from an AT that is activated in that particular burst by a message, 
called Grant, sent by the AP on the downlink channel. 

The MAC Processor of the AP selects the AT that will have access to the radio channel; the operation is performed 
burst by burst by the AP processor and a signalling message is inserted into downlink containing the TID of the relevant 
AT. 
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All ATs will receive all the downlink signalling messages (broadcast mode); the AT decodes all the received messages 
and enables the uplink transmission burst by burst only in case the TID in the grant is assigned to it. 

MAC functionality, located in AP, is in charge of generating these "grant" messages in order to satisfy bandwidth 
requests from ATs. The AP receives requests for transmission rights and grants these requests within the time available. 
The resource allocation protocol consists of these two types of messages: Grant and Request. 

9.2 Grants 

The AP shall use the UL map to allocate bandwidth, i.e. to give grants (see clause 8.4.2). 

The grant shall contain the TID. Following a successful detection of a grant the AT gains access to the related uplink 
burst. 

Figure 38 shows the procedure of the AT when it receives a grant. When an AT receives a grant it shall transmit MAC 
PDUs in order to honour the grant. If the AT has no traffic (data or messages) to transmit it shall send MAC dummy 
PDUs. 




▼ 



Wait for and process 
UL-Map 



V 




Figure 38: Grant per terminal 
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9.3 Requests 

9.3.1 General request strategy 

In the uplink each AT sends to the AP indications about (instantaneous) queue status and instantaneous bandwidth 
needed for bandwidth allocation, i.e. bandwidth requests. Such information will allow the AP to assign the proper 
capacity to each AT. 

Rules for requests: 

• The resource requests shall be on a per connection aggregate basis. 

• The resource requests shall be encoded in aggregate form (i.e. the complete queue status of all connections in 
the relevant group shall be sent). 

The AP decides on the grouping of connections into connection aggregates. The number of connections, connection 
aggregates and maximum number of connections per connection aggregate that the AT can handle simultaneously is 
negotiated between AP and AT during initialization with the RlcOtherCapabilitiesInf o and 
RlcOtherCapabilitiesCnf messages. 

The AP shall not send acknowledgements of resource requests to the AT. 

The three possible signalling mechanisms in the UL for bandwidth requests are specified in the following clauses: 
per MAC PDU header; 

• per RlcBandwidthRequest MAC management message; 

• per queue status report procedure. 

9.3.2 Requests per MAC PDU header 

Every MAC data PDU in the UL transports, within its header, a request for bandwidth allocations. 

The request format is clear from the MAC PDU header for the UL as defined by table 19. A total of 26 bits (3 bytes and 
2 bit) are needed for the bandwidth request: 

• CID (16 bits): the connection ID is exactly that assigned to the particular connection whose PDU is transmitted 
in the burst. The CID associated to the bandwidth request identifies the connection aggregate that MAC Data 
PDU belongs to. 

• PB (8 bits): the request byte (piggyback field) describes the number of PDUs in the queue for the connection 
aggregate associated with the connection aggregate of the MAC data PDU. 

• PM (1 bit): the poll-me bit is used to indicate whether the AT has traffic to send or not for the connection 
aggregates associated to the poll-me bit with the exclusion of the connection aggregate specified by the CID 
field. 

PM = 1 means poll-me and PM = means do not poll-me. 

• RSB (1 bit): a request for an UL grant to send a short MAC signalling PDU. If the AP replies with a grant, 
then this can be used for all MAC management messages that fit into a short MAC signalling PDU, 

e.g. measurement reports, bandwidth request, connection control messages, etc. 

RSB = 1 means request and RSB = means no request. 
The three fields PB, PM and RSB are also addressed as the GM (Grant Management) field with 10 bit. 
The use of RSB is shown in diagram 1 . 
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MSC RGC_ShortPduRequest 



AP 



opt 



< 





AT 









Grant for a 
short PDU needed 



Arbitrary_long_PDU 



(/*set RSB=1 in header 7) 



AP grants a 
short PDU 



Grant_for_a 
short_PDU_ 
v received 



T RSB 



Diagram 1 : MSC for the use of RSB 

9.3.3 Requests per bandwidth request message 

A MAC management messages RlcBandwidthRe quest is defined for the UL to transmit information about the 
queue status of several connection aggregates. This message can be transported in a short MAC signalling PDU and can 
be sent according to the UL frame structure expressed in the UL map (see table 22) as follows: 

• by using the bandwidth request contention window; or 

• by using a granted short MAC signalling PDU. 

The RlcBandwidthRequest message is specified in table 25 and the usage is illustrated in diagram 2. 

Table 25: Message for bandwidth request 



RlcBandwidthReq 
caid2 

piggyback^ 
caid3 

piggyback3 



: := SEQUENCE { 
Caid, 

Piggyback, 

Caid, 

Piggyback 



} 

Caid 

Piggyback 



:= INTEGER (0. 
:= INTEGER (0. 



. 65535) 
.255) 



2 byte, common 

1 byte, common 

2 byte, common 
1 byte, common 



— 16 bit, connection aggregate ID 

— 8 bit, piggyback field 
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MSC RGC_BandwidthRequest 



AP 



AT 



PDUs from different 
CAs to be transmitted. 

Caid1,Caid2,Caid3 
are selected by AT 



Currently no grants (for long PDUs) 

Waiting for 
bandwidth request contention window 
or 

grant for a short PDU 



Headerfields: 
Cid refers to CA1 
Piggyback refers to CA1 
poll- me refers to CA4+CA5+.. 

Payload contains only info 
about CA2 and CA3 



RIcBandwidthReq 



r Caid2,Piggyback2,Caid3,Piggyback3 */) 



Transmitted in the bandwidth 
request contention window or 
in a granted short PDU 



Give grant for one or 
several MAC PDUs 



AdditionaL 
grants_received 



T_BandwidthReq 



regular_UL_traffic 



/ 1AC PDUs can be transmitted 
according to the received grants 



Diagram 2: MSC for bandwidth request message 

The three connection aggregates that are referred to in the message RIcBandwidthReq can be selected by the AT 
without any restrictions. 



9.3.4 AP-requested queue status report 

The AP can request an AT to report the queue status of up to six connection aggregates. The DL message 
RlcQueueStatusReq contains the identities of up to six connection aggregates. The UL message 
RlcQueueStatusRsp contains only the corresponding piggyback bytes (as for the MAC PDU headers and for 
RIcBandwidthReq) describing the queue status of the connection aggregates. 

The restriction to six connection aggregates ensures that the message RlcQueueStatusRsp can be transmitted in a 
short MAC signalling PDU. After reception of RlcQueueStatusReq, the AT shall use the next granted short PDU 
to transmit RlcQueueStatusRsp. The messages are specified in table 26 and shown in diagram 3. 

Table 26: Messages for queue status report 



RlcQueueStatusReq ::= SEQUENCE ( SIZE ( 1 . . 6 ) ) OF Caid — DL 

RlcQueueStatusRsp ::= SEQUENCE ( SIZE ( 1 . . 6 ) ) OF Piggyback UL 



Caid 

Piggyback 



INTEGER ( . . 65535) 
INTEGER ( . .255) 



16 bit, connection aggregate ID 
8 bit, piggyback field 
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MSC RGC QueueStatus 



AP 



AT 



AP decides to request a report 
on the queue status of up to six 
connection aggregates caid1,caid2,. 



RIcQueueStatusReq 



(/* Caid1,Caid2,... 7) 



AP gives a grant 
for a short PDU 



RIcQueueStatusRsp 



(/* Piggyback! ,Piggyback2,... 7) 



shall be transmitted in the 
first granted short PDU 
after reception of 
RIcQueueStatusReq 



Diagram 3: MSC for queue status report 

9.4 Allocation mechanisms 

Different allocations mechanisms are defined to be suitable for different types of traffic. 

9.4.1 Continuous grant 

Continuous Grant is the periodic assignment of transmission burst to ATs with a fixed rate. It corresponds to the 
assignment of a fixed capacity, equal to a constant grant rate, to a certain AT, that is a certain group of connections with 
constant traffic profile. This predetermined capacity to each requesting AT shall be guaranteed. 

The AP is not influenced by the status of the queue related to the static allocation connections. For these connections 
there is no need for AT to transmit Request information. The periodicity of bandwidth assignment is defined at the 
connection establishment by the QoS parameters. 

Continuous grant is usually applied to CBR traffic. 



9.4.2 



Polling 



Polling is the process by which the AP allocates to the ATs bandwidth specifically for the purpose of making bandwidth 
requests. These allocations shall be to individual ATs. The AP polls the ATs that will send a short MAC signalling PDU 
the bandwidth request. If the polled AT has no traffic to transmit the request sent shall be empty. 

Note that polling is done on a per AT basis, bandwidth is requested on per connection aggregate basis, and bandwidth is 
allocated on per AT basis. 



The AP shall have the full control of the mechanism. 
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9.4.3 



Piggyback 



All the MAC data PDUs have within the header a bandwidth request field. The piggyback byte describes the number of 
PDUs in the queue for the connection aggregate including the connection of the MAC data PDU. 

The first 255 combinations refer to to 254 data PDUs, the last all-one combination means 255 or more PDUs in the 
queue. 

The use of piggyback is sketched in figure 39. 



Poll-me bit is a form of piggyback mechanism. It's a request of polling and the format is represented by one bit added in 
every PDU header. 

During the connection set-up procedure, the configuration of the poll-me bit, active or non-active, is set in conformance 
to the connection aggregate the connection belongs to. The configuration of the poll-me bit is under the full control of 



The poll-me bit shall be used to indicate whether the AT has traffic to send or not for the connection aggregates 
associated with the poll-me bit with the exclusion of the one that the CID of the MAC PDU belongs to. 

The use of poll-me bit and piggyback is sketched in figure 39. 



9.4.4 



Poll-me bit 



the AP. 
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Yes 



Set piggybacks of PDUs in 
the queue in the MAC PDU 
header 



Set piggybacks) in the MAC 
PDU header 



Send MAC 
PDU 




Figure 39: Usage of piggyback and poll-me bit by an AT 



9.4.5 Contention reservation 

With a specific grant, an UL burst is dedicated to contention requests. This kind of grant is broadcasted to all the ATs 
(or a subset of), and ATs could submit a contention request in this burst via a short MAC signalling PDU. 

The implementation of the bandwidth request contention procedure is optional for both sides. 



9.5 Contention resolution 

The bandwidth request contention window may consist of a number of transmission opportunities, which depend on the 
size of the contention window. 
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9.5.1 



Contention resolution algorithm 



The contention resolution algorithm shall be based on a truncated binary exponential back-off algorithm, where the 
initial back-off window and the maximum back-off window shall be controlled by the AP. The size of the back-off 
window shall be broadcasted periodically to all ATs via the GBI message. These values shall represent a power-of-two 
value. For example, a value of 4 indicates a window between and 15 while a value of 10 indicates a window between 
and 1 023. 

When an AT has information to send and wants to enter the contention resolution process: 

1) the AT shall set its internal back-off window equal to the initial back-off window defined in the GBI message 
currently in effect; 

2) the AT shall randomly select a number within its internal back-off window indicating the number of 
contention transmission opportunities that the AT shall defer before transmitting; 

3) the AT shall consider the contention transmission lost if no response has been given within the time in which 
they were to be received; 

4) the AT shall increase its back-off window by a factor of two (as long as it is less than the maximum back-off 
window defined in the GBI message currently in effect) if the contention transmission is lost; 

5) the AT shall randomly select a another number within its new back-off window and repeat the deferring 
process described above if the contention transmission is lost; 

6) the retry process shall continue until a maximum number of retries (broadcasted in the GBI message) (say 
16 retries, for example) has been reached. 



The bandwidth request contention window shall be scheduled in the uplink with a particular UIUC entry in the UL map. 
This contention window can be used by all ATs that are requesting for a bandwidth grant. In this contention window 
only short MAC signalling PDU shall be transmitted. 

If the AT receives a granted uplink burst at any time while deferring, it shall stop the contention resolution process and 
use the explicit transmission opportunity for bandwidth request. 

If bandwidth request contention process continues to fail, after the maximum number of retries is reached the AT shall 
wait for a regular grant in order to request bandwidth using poll-me bit or piggyback mechanism. 



9.5.2 



Bandwidth request contention window 
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In figure 40 is sketched the bandwidth request contention process performed by an AT. 



Set z = 2z 



No 




Yes 



Yes 



Set internal back-off (z) equal to the initial 
back-off window defined in the UCD 



Set a number (x) within z randomly 




Wait for bandwidth 
contention window 




No 



Perform the transmission in the x 1 
opportunity 




( Waiti 



Waiting for a regular 



grant 



Yes 




Yes 



Figure 40: Contention algorithm for bandwidth request 



1 Initialization control (IC) 
10.1 Overview 

Initialization is the procedure that occurs when an AT enters into the network. At the end of the initialization process 
the AT becomes operational. Initialization is a general term that includes the following cases: 

• A new AT enters into the network. 

• After PSI (Power Supply Interruption), breakdown or replacement of AT equipment. 

• An already initialized AT loses the radio link; this may happen due to deep rain fading or co-channel 
interference (may affect both or only one direction). 

• Malfunction of the AP, e.g. loss of the status of the AT and its parameters or breakdown of the AP. 

In the first two cases the process is named first initialization, while in the other two cases the process is named 
re-initialization. Differences between first initialization and re-initialization are mainly related to the fact that during 
re-initialization a new frequency scanning procedure is not required and consequently the process of re-initialization is 
easier and faster. 
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Initialization is always invited, i.e. the AP knows the AT MAC address in advance and the AP knows when to perform 
a first initialization (e.g. AP knows that AT need initial access) or re-initialization (e.g. AP is aware of link 
interruptions). 

1 0.2 Process of initialization 

The initialization process shall be divided into the following steps: 

• DL frequency scanning (search all DL channels of full RF block). 

• Synchronization acquisition (carrier, phase, clock, by processing the DL frame preamble). 

• UL and DL transmission parameters acquisition (by decoding the control zone in PHY mode #0 and the PHY 
mode region #1 used for broadcast messages including the reception of the broadcasted GBI message 

RlcGeneralBroadca st Information). 

• Initial ranging: during this phase of UL and DL transmissions the AT gets: 

TID (to be used instead of AT MAC address for all other addressing or identification of AT). 

CIDs for management connections (basic, primary and secondary). 

Transmit timing offset (and thus TD and RTD), including fine-tuning. 

UL transmit power level, including fine-tuning. 

NOTE: Timing and transmit power settings are also updated during regular operation by the message 
RlcUplinkCorrection. 

The whole UL communication during ranging is restricted to the use of granted UL ranging bursts. 

From the AP point of view, after reception of the RlcRangingAck message the ranging process is finished and the 
AP shall start to give regular grants. 

From the AT point of view, after reception of the RlcRangingSuccess message and reception of another message 
not related to ranging, the ranging process is finished. 

• Physical capabilities negotiation (informs AP about ATs DL and UL PHY capabilities and AP commands on 
what to use). 

• AT authentication (including AK transmission). 

• Other AT capabilities negotiation (maximum numbers of CIDs and CAs, etc.). 

After these steps the AT is called operational and connections can be established (and allocated to connection 
aggregates and security associations). 
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The overview of the entire initialization process is reported in diagram 4, where the upper left entry refers to first 
initialization when an AT enters the network for the first time and the upper right entry represents the situation after a 
link loss. 



MSC ICJnitializationOverview 



KD 



T_not_installed 



LA 



Downlink_frequency_scanning_ 
according_to_list 



LA 



Synchronisation_aquisition 



and_DL_parameters_aquisition 



IC_Ranging 



[C_PhyCapabilitiesNegotiation 



3 



SC_Authentication 



3 



C_OtherCapabilitiesNegotiation 



CC_AT_init_ 
_Connection_ 
_Addition 



V 



CC_AP_init_ 
_Connection_ 
Addition 



x Link_Loss 



Start_with_old_carrier 

v , J 



not succesful 



-0 



successful 



CapabilitiesNegotiation 
and 

Authentication 
on request of AP 



Diagram 4: HMSC for AT activities and states for initialization (update) 
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1 0.3 Steps from frequency scanning to downlink synchronization 

10.3.1 Frequency scanning 

The first operation that the AT shall perform is the frequency scanning. Before installation the list of possible downlink 
RF channels (all downlink frequency available in the RF block assigned to an operator), that AT shall scan during this 
phase, shall be stored in the AT non-volatile storage. Any change on this list shall be communicated by the 

RlcFrequencyList message. 

The AT shall order all scanned frequencies in a descending order based on the signal strength and select the frequency 
with the strongest received DL signal power. 

The frequency scanning step during re -initialization is very similar to that during initialization with the simplification 
that AT shall try to find before the DL frequency used during previous operations. If AT does not find this frequency, 
then it shall go to next frequency in the ordered list of frequencies. 

10.3.2 Synchronization acquisition 

The AT modem shall synchronize, in time and frequency, to the preamble of the DL frame. Once the PHY layer has 
achieved synchronization, the MAC sublayer shall decode the control zone. As it has received and decoded at least one 
control zone, the AT achieves the frame synchronization and remains synchronized until it fails to receive or decode 
control zones. If the timer T_synchronization elapsed before a map has been received and decoded, the AT shall come 
back to the DL frequency scanning step. The synchronization acquisition step shall be as in figure 41. 



procedure synchronization_acquisition 1(1) 

; FPAR IN/OUT synchAquired Boolean; 



set 

(T_synhronization) 



I 

Syncronising 



T_synhronization 



Internal signal generated 
when Uplink map is 
succefully decoded 



synchAquired : 
false 



DLmapDecoded 
(sidReceived)\ 



synchAquired := 
true 



reset 

(T_synhronization) 





Figure 41 : Synchronization acquisition 
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10.3.3 APC identification 

After the AT synchronizes, it shall be sure to be on the right APC. It may compare the APC-ID introduced in its non- 
volatile memory before installation to the APC-ID received in the frame control zone. If those are equal, the AT shall 
proceed with the initialization process, otherwise the DL frequency channel previously selected during the frequency 
scanning step does not belong to the right sector and the AT should use the next frequency in the ordered list of 
frequencies. 

The probability that the AT selects a frequency, that does not belong to the APC that the AT should be paired to, is very 
low, but not negligible in a deployment with a very high frequency re-use. The use of APC-ID, transmitted in each 
frame, facilitates and speeds up the initialization process and avoids that any message is sent from the AT to the AP if 
this one is not the right one. 



procedure apcldentification 1(1) 

;FPAR IN/OUT apcldentified Boolean; 













jcldentified := 
(apcReceived = 
apcInMemory) 







true if the same 



Figure 42: APC identification 
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1 0.3.4 UL and DL parameters acquisition 

In order to retrieve the right set of transmission parameters, the AT shall wait for a GBI message. The GBI message 
contains general broadcast information as specified in clause 8.8, important parameters especially for the initialization 
are the power increment step for ranging and the period of the ranging invitation. The GBI message shall be 
broadcasted with a certain periodicity defined by the operator (where the specification of a formal period is not 
required). 

The procedure for parameters acquisition is summarized in figure 43. 



procedure UL_and_DL_parameters_acqusition 1(1) 




I I. and 1)1. \ 

_parameters_ 
_acquisition 



RlcGeneral 
Broadcast_ 
Information (gl 



'Select DL PHY 
mode from 
phyModeSet_ 
'. 3e scrip to rC urrent 




Figure 43: UL and DL parameters acquisition 
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10.3.5 Summary 

All initialization steps from the start up to the AT operational status are summarized in figure 44 with special emphasis 
on frequency scanning. 



Frequency scanning (AT side) 



Legend: 



AT expected to initialize 



update 



Read frequency list (RF block) 



Scan frequencies 



I 

t 



Link loss or PSI 



Scanning 
completed 



Use best 



Use old 




DL synchronization aqisition 



Successful 



Check APC-ID 



Failure 



No match 
for APC-ID 



Successful 



Ranging 



DL sync loss 

No mach for 

AT MAC address , 



Successful 



Capabilities Negotiation, Authentication 



DL sync loss 



DL sync loss 



Successful 



RlcFrequencyList received 



AT operational 



DL sync loss 



Figure 44: Frequency scanning in the context of initialization steps 
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10.4 Ranging 
10.4.1 Overview 

The ranging process is required in order that the AT shall be able to get: 

• the right timing offset so that its transmission is aligned to a symbol that marks the beginning of MAC frame 
(the PHY layer timing delays shall be relatively constant); and 

• the right Tx power parameters that it will use during normal operations. 

The ranging process shall be started as soon as the AT has acquired the right frequency, synchronization and uplink 
transmission parameters and after the reception of the RlcRanginglnvitation message. The 
RlcRanginglnvitation message contains the AT MAC address to identify the AT and provides the binding 
between the AT MAC address and the TID. Moreover, the RlcRanginglnvitation message contains the CIDs 
and CAIDs for the three management connections and the current power level of the transmitted signal of the AP 
(apTxPowerlndication parameter). 

After reception of the RlcRanginglnvitation message and before transmission of the RlcRangingComplete 
messages (including the message itself), the AT is only allowed to transmit with granted ranging bursts. 

The ranging process is started with the reception of the RlcRanginglnvitation message. At this point the AT can 
calculate an estimation of the proper transmission power level to be used in the first ranging burst by analysing the link 
attenuation derived as difference between transmitted and received power in the downlink and applying a proper 
backoff. Exact figures do not need to be standardized provided that the terminal transmits the first ranging burst with a 
somewhat lower power than the operative transmission power. 

The AT uses each ranging grant to send an RlcRangingReg message with increasing transmit power, starting from 
ATtxPower, where the transmit power increments are specified in the GBI message. 

• If the AT receives an RlcRangingContinues message then it adapts its transmit power and timing 
according to this message and waits for next ranging grant to send an RlcRangingReq message. 

• If the AT receives an RlcRangingSuccess message then it adapts its transmit power and timing according 
to this message and waits for the next ranging grant to send an RlcRangingAck message. 

• After transmission of the RlcRangingAck message, the AT has to respond: 

to a ranging grant with the RlcRangingReq message and increased transmit power (error case); 
to a normal grant with a regular transmission (normal case). 

• Whenever the AT receives two subsequent ranging grants without an RlcRangingCont inue or 
RlcRangingSuccess message in between (indicates loss of message in DL), then it shall return to the 
transmit power increase mechanism. The same applies whenever the AT receives two messages without a 
ranging grant in between (AP error). 

The AP shall not give ranging grants in the same frame as it transmits the RlcRangingContinue or 
RlcRangingSuccess message. 

However, it should be noted that there is no rule how to combine RlcRanginglnvitation messages and ranging 
grants, since the first requires DL capacity and the latter UL capacity. So several RlcRanginglnvitation 
messages between two ranging grants are allowed (but not recommended), but also several ranging grants between two 
RlcRanginglnvitation messages (recommended). In other words, RlcRanginglnvitation message and 
ranging grants can be given whenever there is free capacity in the DL or UL frame, so the ranging process does not 
cause any considerable overhead at all. 

If no RlcRanginglnvitation message was transmitted for any AT, then the AP should not give any ranging 
grants. However, if the AT receives a ranging grant without having received an RlcRanginglnvitation message, 
then it shall ignore the ranging grant. 
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A maximum gap between two subsequent RlcRanginglnvitation messages to the same AT shall be transmitted 
in the GBI message in order to limit waiting times during the frequency scanning process. 

If an RlcRanginglnvitation message is received during normal operation, then the AT shall stop all 
transmissions, wait for ranging grants and start from the updated ATtxPower. After reaction to an 
RlcRanginglnvitation message, the AT shall ignore all further RlcRanginglnvitation messages. The AP 
stops issuing RlcRanginglnvitation messages after reception of the first RlcRangingReq message. The AT 
can react again to an RlcRanginglnvitation messages after 

InitializationStatus = InitializationFinished in one of the initialization DL messages. 



1 0.4.2 Messages for Ranging 

The messages for ranging are shown in table 27. 

Table 27: Messages for ranging 



anginglnvitation 


: : = SEQUENCE { 


— DL 






atMacAddress 


AtMacAddress, 


— 48 


bit, 


common 


tid 


Tid, 


— 10 


bit, 


common 


basicCid 


BasicCid, 


— 16 


bit, 


common 


primaryCid 


PrimaryCid, 


— 16 


bit, 


common 


secondaryCid 


SecondaryCid, 


— 16 


bit, 


common 


basicCaid 


Caid, 


— 16 


bit, 


common 


primaryCaid 


Caid, 


— 16 


bit, 


common 


secondaryCaid 


Caid, 


— 16 


bit, 


common 


apTxP owe r Indication 


ApTxP owe r Indication 


— 5 bit, 


common 



} 



RlcRangingReq 
power 

rangingStatus 



RlcRangingCont inue 

timingAd just Ranging 
uplinkPower Inc 

} 

RlcRangingSuccess 

timingAd just Ranging 
uplinkPower Inc 
initializationStatus 

} 

RlcRangingAck 

rangingStatus 

} 

RlcPhyCapabilitiesReq 

} 



= SEQUENCE { 
RangingStatus 



= SEQUENCE { 
TimingAd just Ranging, 
UplinkPower Inc 



= SEQUENCE { 
TimingAd just Ranging, 
UplinkPower Inc, 
InitializationStatus 



= SEQUENCE { 
RangingStatus 



UL, increasing or adapted 
2 bit 



-- DL, adapt power, send Req 
— 13 bit, common 
6 bit, common 



DL, adapt power, send Ack 
13 bit, common 
6 bit, common 
1 bit 



2 bit 



SEQUENCE { 



RlcPhyCapabilitiesInf o : : 
downlink64QamSupport 
uplinkl 6QamSupport 
up linkTurboEnc Support 
uplinkPowerMaxQpsk 
uplinkPowerMaxl 6Qam 
number SaidSupport 
terminal Type 

pairOf Carrie rFrequencies Low 
pairOf CarrierFrequenciesHigh 



SEQUENCE { — AT offers its optional cap. 

Downlink64QamSupport, — 1 bit 



Uplinkl 6QamSupport , -- 1 bit 
UplinkTurboEncSupport , -- 1 bit 
UplinkPowerMax, — 4 bit, 

UplinkPowerMax, — 4 bit, 

NumberSaidSupport, — 10 bit 
TerminalType, -- 1 bit 

PairOfCarrie rFrequencies, 
PairOf Car rierFrequencies 



common 
common 



— 34 

— 34 



bit 
bit 



RlcPhyCapabilitiesCnf 
downlink64QamUse 
uplinkl 6QamUse 



SEQUENCE { 
Downlink64QamUse, 
Uplinkl6QamUse, 



AP commands what to use 

— 1 bit 

— 1 bit 
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uplinkTurboEncUse 
up linkPreamble Length 
uplinkPowerMaxQpsk 
uplinkPowerMaxl 6Qam 
initializationStatus 



UplinkTurboEncUse, — 1 bit 

UplinkPreambleLength, 1 bit 

UplinkPowerMax, — 4 bit, 

UplinkPowerMax, — 4 bit, 

InitializationStatus — 1 bit 



common 
common 



RlcOtherCapabilitiesReq ::= SEQUENCE { 

} 



RlcOtherCapabilities Inf o 



SEQUENCE { 



number Up linkConns Support 
number Down linkConns Support 
numberConnAggs Support 
number Conn sPerConnAggSupport 
crSupport 
tripleDes Support 
terminalClCapabilities 



NumberUplinkConnsSupport , 
NumberDownlinkConnsSupport , 
NumberConnAggsSupport , 
Number Conn sPerConnAggSupport , 
CrSupport, 
TripleDes Support , 
TerminalClCapabilities 



UL 

2 byte 
byte 
byte 
byte 
bit 
bit 



variable 



RlcOtherCapabilitiesCnf ::= 
number Up linkConnsUse 
number Down linkConnsUse 
number ConnAggsUse 
number Conn sPerConnAggUse 
tripleDesUse 



SEQUENCE { 

NumberUplinkConnsUse, 
NumberDownlinkConnsUse, 
Number ConnAggsUse, 
Number Conn sPerConnAggUse, 
TripleDesUse 



RangingStatus 
txPowerMax 
txP owe rBet ween 
txPowerMin 

} 



ENUMERATED { — 2 bit 

(0) , 

(1) , 
(2) 



InitializationStatus ::= ENUMERATED { — 1 bit 

initializationContinue (0), -- AT to expect further messaging for init 

initializationFinished (1) — init finished 

} 



RlcInitializationCmd ::= SEQUENCE { — DL 

initializationCmd InitializationCmd — 3 bit 

} 



InitializationCmd ::= ENUMERATED { 
re jectedFromNetwork (0), 
re jectedFromChannel (1), 
f irstlnitialization (2), 
transmissionStop (3), 
transmissionReStart (4) 



UplinkPreambleLength ::= ENUMERATED { 
lengthl6bit (0), 
length32bit (1) 

} 

Downlink64QamSupport : := ENUMERATED { 

downlink64QamNotSupported (0), 
downlink64QamSupported (1) 

} 

Uplinkl6QamSupport ::= ENUMERATED { 

uplinkl 6QamNotSupported (0), 
uplinkl 6QamSupported (1) 

} 



Downlink64QamUse ::= ENUMERATED 

downlink64QamNotUsed (0), 
downlink64QamUsed (1) 
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} 



Uplinkl 6QamUse 

uplinkl 6QamNotUsed 
uplinkl 6QamUsed 

} 



ENUMERATED { 
(0) , 

(1) 



UplinkTurboEncSupport ::= ENUMERATED 
uplinkTurboEncNotSupported (0), 
uplinkTurboEncSupported (1) 



UplinkTurboEncUse ::= ENUMERATED { 

uplinkTurboEncNotUsed (0), 
uplinkTurboEncUsed (1) 

} 

TerminalType : := ENUMERATED { 

terminalFdd (0), 
terminalHf ddWithTdmAndTdma (1) 

} 

TripleDesSupport : := ENUMERATED { 

tripleDesNotSupported (0), 
tripleDesSupported (1) 

} 



TripleDesUse 

tripleDesNotUsed 
tripleDesUsed 

} 



ENUMERATED { 
(0) , 

(1) 



TerminalClCapabilities 

Number Up linkConns Support 
Number Down linkConns Support 
NumberConnAggs Support 
Number Conn sPerConnAggSupport 



OCTET STRING (SIZE (0.. 32) 



— variable 



INTEGER (4 . . 65535) - 
INTEGER (5 . . 65535 
INTEGER (1 . . 65535 
INTEGER (1 . . 65535 



- 2 byte, incl MAC mgmt conns 

- 2 byte, incl MAC mgmt conns 

- 2 byte 

- 2 byte 



Number SaidSupport 
maxNumberSaidSupport 



: := INTEGER (1 . 
NumberSaidSupport : : 



. maxNumberSaidSupport ) 
= 1023 



10 bit 



Number Up linkConnsUse 
Number Down linkConnsUse 
NumberConnAggsUse 
Number Conn sPerConnAggUse 



INTEGER (4 . . 65535) 
INTEGER (5 . . 65535) 
INTEGER (1 . . 65535) 
INTEGER (1 . . 65535) 



-- 2 byte, incl MAC mgmt conns 

2 byte, incl MAC mgmt conns 

— 2 byte 

— 2 byte 



CrSupport 

crSupportNo 
crSupportYes 

} 



ENUMERATED { 
(0) , 
(1) 
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1 0.4.3 Ranging described with MSC diagrams 

Diagram 5 shows the basic principle of the ranging procedure. 



MSC IC_Ranging 



AP knows AtMacAddress 

Sending repeated until 
RIcRangingReq is received 



Stop sending 
RIcRanginglnvitation 



AP shall continue to grant 
ranging bursts (until 
ranging is finished) 



If RIcRangingAck is not 
received then 
RIcRangingSuccess 
has to be resent 



AP 




AT 











< 



Synchronization_established_ 
RIcGeneralBroadcastlnformation read 



RIcRanginglnvitation 



(/* AtMacAddress,Tid,Cids,Caids, 
ApTxPowerlndication.etc. */ ) 



loop <0, m>J 



RIcRangingReq 



RangingGrant. 
Received 



(/* RangingStatus */) 



RIcRangingReq 



RangingGrant, 
Received 



(/* RangingStatus */) 



loop <0, k>J 

RIcRangingContinue 



T_RangingAck 



AP shall start 
sending regular 
grants 



(/* TimingAdjustFine,UplinkPowerlnc 7) 



RIcRangingReq 



RangingGrant, 
Received 



(/* RangingStatus */) 



RIcRangingSuccess 



(/* TimingAdjustFine.UplinkPowerlnc, 
InitializationStatus 7 ) 



AT is not allowed 
to transmit outside 
of ranging bursts 
unless ranging 
is finished 



Save Tid, Cids 

Further receptions of 
RIcRanginglnvitation 
do not restart the 
ranging process 



several transmissions 
with increasing 
TxPower, until 
RIcRangingContinue or 
RIcRangingSuccess 
is received 



Transmit with the 
increased TxPower 



Transmit with the 
adapted TxPower 




Diagram 5: MSC for the ranging principle 
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Diagram 6 contains an example of the message exchange for ranging, where several messages are lost. 



MSC IC_ExampleRangingNormal 



Syntax: 

Message_FrameNumber_(TX power or TX correction) 



AP ( 


AT 









< 



Synchronization_established_ 
RIcGeneralBroadcastlnformation read 



RangingGrants in frames 
2, 10, 15, 30,34, 37, 41, 43, 47, 52, 60 



1 1 RIcRanging Invitation l 6 



AP does not receive 
since TX power too low 



AP does not receive 
since TX power too low 



After reception: 
RIcRanginglnvitations 
shall be stopped 



Ranging finished 



RIcRanging Invitation l 



RIcRanging lnvitation_20 



RIcRanging lnvitation_27 



RlcRangingReq_30J-20dBm) 



RlcRangingReq_34J-15dBm) 



RlcRangingReq_37_(-10dBm) 



RIcRanging lnvitation_39 



RlcRangingReq_41_(-5dBm) 



RlcRangingReq_43J0dBm) 



RIcRanging lnvitation_45 



RlcRangingReq_47_(+5dBm) 



RIcRanging Co ntinue_50_(correct+2dB) 



RlcRangingReq_52J+7dBm) 



RlcRangingSuccess_58_(correct-1dB) 



RlcRangingAck_60_(+6dBm) 



IC_PhyCapabilities Negotiation 



> 



AT not synchronized 



AT receives 
Ranginglnvitation 
for the first time 



TX power is set to minimum 
and increased for further 
ranging grants 



Adapt TX power 
to +5+2=7 dBm 



Adapt TX power 
to +7-1=+6dBm 



Diagram 6: MSC of a ranging example with many errors 
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1 0.4.4 Ranging described with state diagrams 

Diagrams 7 and 8 describe the ranging process on the AP side and the AT side. 



Ranging (AP side) 



Legend: 

RG = ranging grant 
Inv = RlcRanginglnvitation 
Req = RlcRangingReq 
Cont = RlcRangingContinue 
Succ = RlcRangingSuccess 
Ack = RlcRangingAck 
^ errors 



Link Loss or 
AT expected to initialize 



Start to send irregularly Inv 



Typically if DL scheduler allows 



AT expected: typically if UL scheduler allows 
Link loss: typically often 




Ack was OK 
and T-RangingAck completed 



Ranging completed 



Diagram 7: State diagram for ranging (AP side) 
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Ranging (AT side) 



Legend: 

RG = ranging grant 
Inv = RlcRanginglnvitation 
Req = RlcRangingReq 
Cont = RlcRangingContinue 
Succ = RlcRangingSuccess 
Ack = RlcRangingAck 
► errors 




Save Tid 
Set PTX=Pmin - Pine 
Ignore all further Inv's (with same Tid) unless ranging is completed 




k — 


; 






Cont or Succ 


RG 




received 


received 



Typically 
one loop 



Cont received 



RG received 



Succ 
received 



Wait for other message 
ranging seems to be complete- 



RG or Cont or Succ received 



Other 
message 
received 




DL sync loss 



DL sync loss 




DL sync loss 



DL sync loss 



DL sync loss 



Diagram 8: State diagram for ranging (AT side) 
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10.5 Capabilities negotiation and authentication 

This procedure includes three steps: PHY capabilities negotiation, authentication of AT against AP and other 
capabilities negotiation. 

1 0.5.1 Physical capabilities negotiation 

After completion of the ranging process, the AT shall inform AP of its physical capabilities. In order to let the AP 
decide on whether this step can be skipped for re-initialization, a 3-way protocol is used. 

The AP starts the procedure by sending RlcPhyCapabilitiesReq, the AT informs with 

RlcPhyCapabilitiesInf o and the AP terminates with RlcPhyCapabilitiesCnf . The following features 
are negotiated: 

64 QAM in DL. 

• 16 QAM in UL. 

• Support of Turbo encoding. 

• Maximum UL transmit power for QPSK. 

• Maximum UL transmit power for 16 QAM. 

• Terminal type (FDD with TDM only or H-FDD with both TDM and TDM A). 

• Uplink preamble length (16 or 32 symbols, the support of both lengths is mandatory for the AT). 

• Number of SAIDs. 

• Supported RF frequency range (AT informs only). 

The messages for PHY capabilities negotiation are shown in table 28. 



Table 28: Messages for physical capabilities negotiation 



RlcPhyCapabilitiesReq : 

} 


:= SEQUENCE { — DL 




RlcPhyCapabilitiesInf o ::= SEQUENCE { — UL 
downlink64QamSupport Downlink64QamSupport , 
uplinkl 6QamSupport Uplinkl 6QamSupport , 
up linkTurboEnc Support Up linkTurboEnc Support , 
uplinkPowerMaxQpsk UplinkPowerMax, 
uplinkPowerMaxl 6Qam UplinkPowerMax, 
number SaidSupport Number SaidSupport , 
terminalType TerminalType, 
pairOf CarrierFrequenciesLow PairOf CarrierFrequencies , 
pairOf CarrierFrequenciesHigh PairOf CarrierFrequencies 

} 


— 1 bit 

— 1 bit 

— 1 bit 

4 bit, common 
4 bit, common 

— 10 bit 

— 1 bit 

— 34 bit 

— 34 bit 


RlcPhyCapabilitiesCnf ::= 
downlink64QamUse 
uplinkl 6QamUse 
uplinkTurboEncUse 
up linkPreamble Length 
uplinkPowerMaxQpsk 
uplinkPowerMaxl 6Qam 
initializationStatus 

} 


SEQUENCE { — DL 
Downlink64QamUse, — 1 bit 
Uplinkl6QamUse, — 1 bit 
UplinkTurboEncUse, — 1 bit 
UplinkPreambleLength, — 1 bit 
UplinkPowerMax, — 4 bit, 
UplinkPowerMax, — 4 bit, 
InitializationStatus -- 1 bit 


common 
common 


UplinkPreambleLength : : 
lengthl 6bit 
length32bit 

} 


= ENUMERATED { 
(0) , 
(1) 




Downlink64QamSupport : : 


= ENUMERATED { 
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downlink64QamNotSupported (0), 
downlink64QamSupported (1) 



Uplinkl6QamSupport ::= ENUMERATED { 

uplinkl 6QamNotSupported (0), 



uplinkl 6QamSupported 



} 



(1) 



Downlink64QamUse : 
downlink64QamNotUsed 
downlink64QamUsed 

} 



ENUMERATED { 
(0) , 

(1) 



Uplinkl 6QamUse 

uplinkl 6QamNot Used 
uplinkl 6QamUsed 



ENUMERATED { 
(0) , 
(1) 



UplinkTurboEncSupport ::= ENUMERATED { 
uplinkTurboEncNotSupported (0), 
uplinkTurboEncSupported (1) 

} 

UplinkTurboEncUse ::= ENUMERATED { 

uplinkTurboEncNotUsed (0), 
uplinkTurboEncUsed (1) 

} 

TerminalType ::= ENUMERATED { 

terminalFdd ( ) , 

terminalHf ddWithTdmAndTdma (1) 

} 



Number SaidSupport 
maxNumberSaidSupport 



: := INTEGER (1. .maxNumberSaidSupport) 
NumberSaidSupport ::= 1023 



10 bit 



InitializationStatus : : 

initializationContinue 



initializationFinished 



■■ ENUMERATED { — 1 bit 

(0) , AT to expect further messaging 

— for initialization 

(1) — initialization finished 



} 



PairOf CarrierFrequencies ::= SEQUENCE { 

uplinkCarrierFrequency Carrie rFrequency, 

downlinkCarrierFrequency CarrierFrequency — equal to uplinkFrequency for TDD 

} 



CarrierFrequency 



INTEGER ( . . 65000) 



17 bit, granu=0,5 5MHz, range=[0,65] GHz 



The InitializationStatus parameter informs the AT: 

• if InitializationStatus = initializationContinue, then further initialization steps have to 
be performed; 

• if InitializationStatus = initializationFinished, then the initialization is now finished 
and the AT can start connection setups and can start requesting for DL PHY mode changes. 
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The PHY capabilities negotiation procedure is described by the MSC in diagram 9. 



MSC IC_PhyCapabilitiesNegotiation 



< 



AP 




AT 











Rangingcompleted 



AP can control if this 
is part of re-initialization 



T_PhyCapabilitiesReq 



T_PhyCapabilitiesCnf 



RIcPhyCapabilitiesReq 



RlcPhyCapabilitieslnfo 



(/* 64Qam,16Qam,PTC,TxPowerMax,numberSaid, 
terminalType.CarrierFrequencyRange. 7) 



RlcPhyCapabilitiesCnf 



(/* 64Qam,16Qam,PTC,PreambleLength, 
TxPowerMaxQpsk,TxPowerMax1 6Qam, 
InitializationStatus 7 ) 



PTC not allowed 

(possibilities: 

one additional UIUC or 

AP to give short grants) 



T_PhyCapabilitieslnfo 



T_PhyCapabilitiesCnf 



Diagram 9: MSC for PHY capabilities negotiation 

It is important that the AT does not use Turbo codes for the transmission of RlcPhyCapabilitieslnfo since the 
use of Turbo codes is just negotiated with these messages. This can be achieved in either one of the following two 
ways: 

• The AP grants only short PDUs at this stage of initialization (Turbo codes are only applicable for long PDUs). 

• The AP assumes no Turbo codes for the decoding of this message and the AT does not use Turbo codes 
without the reception of the commanding message RlcPhyCapabilitiesCnf . 



10.5.2 Authentication 

The authentication step is described in clause 12. 
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1 0.5.3 Other capabilities negotiation 

After ranging and authentication, AT shall negotiate with the AP the other parameters that shall be used. As for the 
PHY capabilities negotiation, again a 3-way protocol is used with a similar structure. The AP starts the procedure by 
sending RlcOtherCapabilitiesReq, the AT informs with RlcOtherCapabilitiesInf o and the AP 
terminates with RlcOtherCapabilitiesCnf . The following features are negotiated: 

The number of uplink connections (hence CIDs) the AT can support. 

The number of downlink connections (hence CIDs) the AT can support. 

The number of simultaneous connection aggregates the AT can support. 

The maximum number of connections per connection aggregate the AT can properly handle. 

The maximum number of security associates the AT can support. 

The AT informs about its support for contention resolution mechanism (no reply in DL required). 
Support of triple-DES by AT and AP for encryption of the MAC data PDUs. 

AT informs about its CL capabilities. The exchange of this information between DLC and CL is not specified. 
The messages for other capabilities negotiation are shown in table 29. 

Table 29: Messages for other capabilities negotiation (update) 



RlcOtherCapabilitiesReq 

} 



RlcOtherCapabilitiesInf o 



SEQUENCE { 



SEQUENCE { 



number Up linkConns Support 
number Down linkConns Support 
numberConnAggs Support 
number Conn sPerConnAggSupport 
crSupport 
tripleDes Support 
terminalClCapabilities 



NumberUplinkConnsSupport , 
NumberDownlinkConns Support , 
NumberConnAggsSupport , 
NumberConnsPerConnAggSupport , 
CrSupport , 
TripleDes Support , 
TerminalClCapabilities 



RlcOtherCapabilitiesCnf 
number Up linkConnsUse 
number Down linkConnsUse 
numberConnAggsUse 
number Conn sPerConnAggUse 
tripleDesUse 

} 

NumberUplinkConnsSupport 
NumberDownlinkConns Support 
NumberConnAggsSupport 
NumberConnsPerConnAggSupport 

Number Up linkConnsUse 
Number Down linkConnsUse 
NumberConnAggsUse 
Number Conn sPerConnAggUse 

CrSupport 

crSupportNo 
crSupportYes 

} 

TerminalClCapabilities : 

TripleDesSupport : : 

tripleDesNot Supported 
tripleDes Supported 



SEQUENCE { 



NumberUplinkConnsUse, 
Number D own linkConnsUse, 
NumberConnAggsUse, 
NumberConnsPerConnAggUse, 
TripleDesUse 



= INTEGER 

= INTEGER 

= INTEGER 

= INTEGER 

= INTEGER 

= INTEGER 

= INTEGER 

= INTEGER 

■ ENUMERATED { 
(0) , 
(1) 



= OCTET STRING (SIZE (0.. 32) 

ENUMERATED { 
(0) , 
(1) 
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} 

TripleDesUse 


: : = ENUMERATED { 


tripleDesNotUsed 


(0) , 


tripleDesUsed 

} 


(1) 



The PHY capabilities negotiation procedure is described by the MSC in diagram 10. 



MSC IC_OtherCapabilitiesNegotiation 



AP can control if this 
is part of re-initialization 



AP 



TOtherCapabilities Req 



T_OtherCapabilitiesCnf 



AT 



RIcOtherCapabilitiesReq 



RlcOtherCapabilitieslnfo 



(/* #conns, #CAs, CrSupport, TripleDesSupport, 
terminalCICapabilities 7) 



RlcOtherCapabilitiesCnf 



(/* #conns, #conn_aggs, tripleDesUse 7) 



T_OtherCapabilitieslnfo 



-X 



T_OtherCapabilitiesCnf 



Diagram 10: MSC for other capabilities negotiation 



1 1 Radio Resource Control (RRC) 
11.1 Overview 

Radio Resource Control (RRC) is an important part of the Radio Link Control (RLC) sublayer as shown in figure 4. The 
other three RLC functions are initialization control (IC, see clause 10), security control (SC, see clause 12) and 
connection control (CC, see clause 13). It should be noted that ARQ is not allocated to the same level but is part of the 
MAC sublayer (see clause 8.5). 

The main functions for radio resource control include the supervision of the radio link (and the start of a new 
initialization procedure if required), the adaptive change of the DL and UL PHY modes (i.e. adaptive coding and 
modulation) and the automatic power control for DL (optional) and UL. Other parts are the change of the PHY mode 
set, load-levelling (inter-channel handover) and the control of the UL structure (i.e. number of FEC blocks per 
preamble, number of MAC PDUs per UL burst). The present document describes: 

• all messages required for the report of measurements and the exchange of information between AT and AP 
(e.g. measurement of C/N, transmit power and received power); 

• all messages or mechanisms for the synchronized change of a parameter (e.g. PHY mode or transmit power or 
carrier frequency); 

• the responsibility (i.e. whether AP or AT or both can or shall change a parameter). 
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The algorithms and the criteria for a change of a parameter are implementation-specific in most cases and therefore not 
addressed in the present document. 

11.2 Link supervision 

1 1 .2.1 Detection of link loss 

Possible reasons for link interruptions are as follows: 

• Deep rain fading event (applies for DL and UL). 

• Interference from other AP (applies for DL, typically time-invariant) or from other AT (applies for UL, 
typically time- variant). 

• PSI (Power Supply Interruption) at AP or AT (affects both DL and UL). 

• Equipment failure at AP or AT (with impact on transmit or receive direction or both directions). 

The detection of a link interruption is based on the fact that AP gives grants to each AT on a regular basis even if the 
AT has no traffic data to transmit (the replies to these grants are needed to allow for UL channel measurements at the 
AP, see clause 11.3). 

• If the DL is interrupted, then the AT can detect this by failing to decode the control zone. Since the AT cannot 
reply to the regular grants from the AP, the AP shall be able to detect the link interruption. 

• If the UL is interrupted, then the AP will detect this since the replies of the AT to the regular grants are 
missing. The AT might not be able to detect the UL interruption very soon. 

If the AT receives grants for each frame, then the AP can detect the DL or UL interruption very fast. The AP can detect 
the link interruption after one or several missing replies in at least two subsequent frames. 

11.2.2 Reaction on link loss 

As a basic principle, the reaction to a link interruption shall be under full control of the AP. 

For the definition or detection of a link loss at the AT side and the appropriate reaction of the AT it is not required to 
define any timers. For the AP side, timers might be required but these are implementation-specific and out of the scope 
of the present document. 

The AT shall always try to maintain or to re-establish as soon as possible the synchronization of the DL (on the same 
RF channel as before) and to decode the control zone and PHY mode region #1 in order to receive or wait for 
commands from the AP. 

The AP shall react on a link interruption by sending the ranging invitation RlcRanginglnvitation and by giving 
ranging grants to the AT. During the re-initialization process, the AP can command whether the PHY and other 
capabilities steps and the authentication and key distribution steps shall be skipped or re-performed. The AP can also 
use the initialization command RlcInitializationCmd for this situation. 

The AT shall delete all connection and security settings after reception of a ranging invitation. 

The details for AT reaction in case of link loss and during regular operation are shown in diagram 1 1 and also specified 
below: 

• If the AT receives a ranging grant during regular operation or after a link interruption without having received 
a ranging invitation, then this ranging grant shall be ignored. This situation can only occur for specific error 
scenarios. 

• If the AT receives an RlcRanginglnvitation during regular operation or after a link interruption, then it 
shall stop all transmissions (if applicable) and shall not reply to any grants other than ranging grants (if 
applicable) and shall start the ranging procedure and the capabilities negotiation steps (if commanded) by 
using the granted ranging bursts. 
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• During the ranging process, repeated RlcRanging Invitation messages shall be ignored after reception 
of the first RlcRanginglnvitation message. 

• If the AT lost the DL synchronization (i.e. failed to decode the control zone), then it shall try to re-establish the 
DL synchronization and wait for further commands. 

The details for AP reaction in case of link loss are specified below: 

• If the AT does not reply to grants, then the AP shall start to issue irregularly RlcRanginglnvitation 
messages and irregularly ranging grants. 



procedure RRC_LinkSupervision_AT_Side 



AT_operational 



KD 



AT_receives_ 

grant_[except_< 

ranging_grant] 



RlcRanging_ 
Invitation 



IC_Ranging 



Capabilities_ 
negotiation 



Ranging. 


^rant 






ignc 


re 



r 



AT_operational 



Diagram 11 : SDL diagram for link loss reaction (AT side) (update) 



An example for the link supervision at the AP side is shown in diagram 12. In this case, the AP commands a 
re -initialization by sending the ranging invitation message after two missing replies to regular grants. The example of 
two missing grants could be reasonable to ensure a fast reaction in case that the AT has no traffic data to transmit 
(i.e. there are only replies to periodic grants that are needed to maintain a minimum traffic load in the UL). In other 
cases with high data rates in the UL of the respective AT, more missing replies could be tolerated in order to avoid 
unnecessary re -initializations. 
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procedure RRC_LinkSupervision_AP_Side 



Example for 
Link Supervision 
at AP side 



1(1) 



AT_operational 



Grant_needed_ 
[from_scheduleV 




RlcRanging_ 
Invitation 




IC_Ranging 



Capabilities. 
Negotiation 



AT_operational 



Diagram 12: SDL diagram for link loss supervision and reaction (AP side, example) 
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1 1 .2.3 Reaction on AT malfunction 

In case of a malfunction of the AT the following procedures shall be applied: 

• If the DL operation fails then the AT can not establish or re-establish synchronization. The AT can not react on 
ranging grants or ranging invitations. After some time, the AP is aware of this and can decide to stop any 
ranging grants or ranging invitations to this AT. The AT does not transmit anything and additional 
specifications are not given. 

• If the UL operations fails or if there is some malfunction (e.g. UL transmit power too high or uncontrollable), 
then the AP can switch off the AT with the RlcInitializationCmd message shown in table 30. 

Table 30: Message for initialization commands 

RlcInitializationCmd ::= SEQUENCE { — DL 

initializationCmd InitializationCmd — 3 bit 

} 

InitializationCmd ::= ENUMERATED { 

re jectedFromNetwork (0) , 

re jectedFromChannel (1), 

f irstlnitialization (2), 

transmissionStop (3), 

transmissionReStart (4) 

} 



For the parameter InitializationCmd, the following rules shall be applied: 

• InitializationCmd = re jectedFromNetwork: the AT shall stop all transmissions and the 
reception and shall not try to synchronize to the network again. The AP shall not give any grants to the AT 
after this command. 

• InitializationCmd = re jectedFromChannel: the AT shall stop all transmissions and the 
reception and shall not try to synchronize to the same RF channel again. The AT shall be reset completely. The 
AT is allowed to perform frequency scanning. The AP shall not give any grants to the AT after this command. 

• InitializationCmd = f irstlnitialization: the AT shall stop all transmissions. The AT shall 
be reset completely and then shall perform a first initialization procedure on the same carrier, started with 
RlcRanginglnvitation. The AP shall not give any grants to the AT after this command except for 
ranging grants. 

• InitializationCmd = transmissionStop: the AT shall stop all transmissions but continue to 
receive and wait for further commands. The AT shall react on 
InitializationStatus = transmissionReStart (or on other values of 

InitializationStatus if applicable) or on RlcRanginglnvitation. The AP shall not give grants 
to the AT after this command except for ranging grants. 

• InitializationCmd = transmissionReStart: the AT shall reply to all grants and can use the 
bandwidth request contention window. It is recommended to use this command only after a short period of 
silence since the link conditions may have changed otherwise. 
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If the AT does not react on RlcInitializationCmd as expected from the AP, then the AP shall re-send the 
command again as shown in diagram 13. 



MSC RRC InitializationCommand 



AP 




AT 











LinkLoss_or_ApDetectslrregularBehaviourOfAt 



TJnitializationCmd 

X — 



RlcInitializationCmd 



(/* InitializationCmd 7) 



Wait for appropriate 
AT actions 
(depending on 
InitializationStatus) 



%- 



Switch off 
or 

wait for RIcRanginglnvitation 
or 

stop transmission 
or 

re-start transmission 

(depending on 
InitializationStatus) 



Diagram 13: MSC for initialization command 

1 1 .2.4 Performance monitoring 

There might be a need for reports from AT to AP on performance monitoring and on information concerning events 
relevant for NMS. These reports are transmitted via the AT-specific secondary MAC management connection and are 
out of the scope of the present document. 

1 1 .3 Change of PHY mode, ATPC and ATTC 



11.3.1 Overview 

The PHY mode (modulation and coding scheme) is adaptive both for DL and UL and the adaptive operation shall be 
supported by AP and AT. The automatic transmit power control is mandatory for the uplink (UL ATPC) and shall be 
supported by AP and AT, but optional for the downlink (DL ATPC). The support of the automatic UL transmit timing 
control (UL ATTC) is mandatory. 

The commanding of new PHY modes and updating of transmit power is summarized as follows: 

1) Usually an AT receives all its MAC PDUs for unicast connections in the currently highest PHY mode region, 
and additionally all PHY mode regions between the current highest PHY mode (inclusive) and the most robust 
PHY mode (inclusive) shall be monitored by each AT to ensure the reception of broadcast and multicast 
connections. The DL map only contains the starting symbols (SS) of the PHY mode regions but no 
information on the allocation of ATs to PHY mode regions. 

The allocation of an AT to a PHY mode region shall be announced from AP to AT (where this shall be done in 
advance in case of changing to a more efficient PHY mode, and shall be done after switching in case of 
changing to a more robust PHY mode) and shall be acknowledged by the AT. 
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A new DL PHY mode can be requested by the AT if certain C/(N + I) thresholds (derived from the received 
and decoded DL signal) are crossed (where the thresholds themselves are commended by the AP to the ATs in 
the GBI message) as well as commanded by the AP. 

2) The DL transmit power for the complete sector can be changed by the AP without notifying the ATs in 
advance. The DL transmit power shall be increased only if the current DL transmit power is not high enough 
for at least one AT in the most robust PHY mode. The DL ATPC is an optional feature. 

3) The UL PHY mode is commanded from AP to AT by addressing each active AT (i.e. ATs that receive grants) 
in the UL map. Each UL map entry consists of the triplet UIUC, TID, SS (where TID is replaced by a specific 
contention window TID for the contention windows). The UL PHY mode is selected in the AP. For the 
contention windows (i.e. for non-granted UL transmissions), the most robust PHY mode shall be used. 

4) The UL transmit power for each AT is commanded by AT-specific MAC management messages (via basic 
MAC management connection) when required, i.e. UL transmit power changes are usually only commanded 
when the rain fading conditions change. During PHY mode switching the AT automatically corrects the 
transmitted power according to the UplinkPowerModChangeList values broadcast in the GBI message. 

The information required at the AP for the appropriate allocation of PHY modes and the appropriate choice of the 
transmit power is gained as follows: 

• The selection of the DL PHY mode and the DL transmit power is under full control of the AP and is based on 
the DL channel measurements at the ATs and the measurement reports from the ATs to the AP. The 
parameters to be measured and the reporting mechanisms are specified in detail in the present document. 

• The selection of the UL PHY mode and the UL transmit power is under full control of the AP and is based on 
the UL channel measurements at the AP. Therefore each AT is granted bandwidth appropriately to maintain a 
minimum traffic load in order to allow for reliable measurements at the AP. More details about the channel 
measurement procedure in the AP and the calculation of the UL parameters are implementation-specific and 
thus out of the scope of the present document. 
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An overview of the DL PHY mode change procedure and the measurement report mechanisms are shown in 
diagram 14. 



MSC RRC_DL_PMC_Overview 



1(1) 




Diagram 14: HMSC for DL PHY mode change and measurement report 



1 1 .3.2 Measurement of uplink RF carrier at AP 

The AP measures the received UL signal from the ATs in order to update its knowledge about the UL radio channels 
from each initialized AT. 



This requires to maintain a minimum traffic load for each AT, i.e. each AT shall be granted bandwidth at least each 
50 ms to 200 ms, depending on the choice of the AP. 

Each AT shall transmit as indicated in the UL map whenever it receives a grant. If no traffic or management 
information is to be transmitted, then a MAC dummy PDU shall be sent. This applies both for grants of long or short 
MAC PDUs. 
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1 1 .3.3 Measurement of downlink RF carrier at AT and measurement 
reports to AP 

The AT shall measure the following two parameters from the received DL signal: 

• CnrMeasured = measured absolute current C/(N + I) from the received and decoded DL signal; 
resolution = 8 bit; range = [4, 40] dB; granularity = 0,25 dB. The measurement accuracy is specified with 1 dB 
and all other details (like averaging period) are implementation-specific. 

• RxPowerMeasured = measured absolute current received power of the DL signal; resolution = 8 bit; 
range = [-88, -28] dBm; granularity = 0,25 dB. 

Both parameters are independent of the current DL PHY mode. The measurement report shall also contain the 
following four parameters: 

• TxPowerMeasured = current UL transmit power of the measurement report; resolution = 6 bit, 
range = [-26, +20] dBm, granularity = 1,0 dB. 

• TxPowerMargin = gap between current uplink transmit power and the maximum uplink transmit power; 
resolution = 6 bit; range = [0, 12] dB; granularity = 0,25 dB. 

• DownlinkPhyModeWanted = wanted PHY mode as a result of CnrMeasured; resolution = 3 bit. 

• MaxUplinkPhyMode = most efficient PHY mode that is possible for the AT with the current transmitted 
power; resolution = 3 bit. 



Table 31 : Message for measurement report 



RlcMeasurementReportData 
down linkPhyModeWan ted 
CnrMeasured 
rxPowerMeasured 
txPowerMeasured 
txPowerMargin 
maxUplinkPhyMode 



: := SEQUENCE { 
DownlinkPhyMode, 
CnrMeasured, 
RxPowerMeasured, 
TxPowerMeasured, 
TxPowerMargin, 
UplinkPhyMode 



UL 

3 bit 
8 bit 
8 bit 
6 bit 
6 bit 
3 bit 



} 

CnrMeasured 
RxPowerMeasured 
TxPowerMeasured 
TxPowerMargin 



DownlinkPhyMode 
noNewPhyMode 
downlinkPhyModel 
downlinkPhyMode2 
downlinkPhyMode3 
downlinkPhyMode4 



= INTEGER(0 . .255) — 8 bit , granu=0 . 2 5dB, range= [ 4 , 4 ] dB 
= INTEGER(0 . .255) — 8 bit , granu=0 . 2 5dB, range= [ -8 8 , -2 8 ] dBm 
= INTEGER (0 .. 63) — 6 bit, granu=l . OOdB, range= [-26, +20 ] dBm 
= INTEGER (0 .. 63) — 6 bit, granu=0 . 25dB, range= [0, 12] dB 

— 3 bit 



ENUMERATED { 
(0) 
(1) 
(2) 
(3) 
(4) 



downlinkPhyModeFutureRe served ( 7 ) 



} 



UplinkPhyMode ::= ENUMERATED { 

undefined (0) , 

uplinkPhyModel (1), 

uplinkPhyMode2 (2), 

uplinkPhyMode3 (3) , 
uplinkPhyModeFutureReserved (7) 

} 



— 3 bit 
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The measurement report RlcMeasurementReportData is specified in table 31 and is transmitted from AT to AP 
in the following cases: 

• If certain C/(N + I) thresholds are crossed, where these thresholds CnrThreshold are broadcasted with the 
GBI message for all PHY modes of the current PHY mode set. The thresholds are different for increasing or 
decreasing channel quality to support hystheresis, see clause 1 1.3.4 for more details. 

• If the parameter MeasurementReportReq in the message RlcUplinkCorrection (used to command 
power or timing correction to the AT) indicates the AP request, see table 34. The AP can control that a 
correction message is always or never or sometimes replied by the report, see table 32. 

• According to the period PeriodReportGeneral in the GBI message. This carrier-specific report period 
can be overwritten by the PeriodReportAtSpecif ic parameter contained in the AT-specific message 
RlcMeasurementReportCriterium, see table 32. Switching on/off of periodic reports is possible on a 
per carrier basis as well as on a per AT basis. 
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MSC RRC_MeasurementReport 



AP 



Case [1] 

for more details, see MSC 

AT_init_DL_PMC_down 

AT_init_DL_PMC_up 



Case [2] 

for more details, see MSC 
PowerTimingCorrection 



Case [3] 



alt 



AT 



C/(N+I) threshold crossed [1] 
or 

UL transmit power / timing updated [2] 
(includes AP-request for report) 
or 

ReportMeasurementPeriod expired [3] 
(optional for AP) 



RIcMeasurementReportData 



(/* DownlinkPhyModeWanted, etc. */) 



RIcDownlinkPhyModeChange 



(/* DownlinkPhyModeGranted */) 



RIcDownlinkPhyModeChangeAck 



(/* DownlinkPhyModeGranted 7) 



RlcUplinkCorrection 



(/* UplinkPowerlnc, TimingAdjustFine, 
MeasurmentReportReq 7 ) 



RIcMeasurementReportData 



(/* DownlinkPhyModeWanted = noNewPhyMode 7) 



RIcMeasurementReportData 



(/* DownlinkPhyModeWanted = noNewPhyMode 7) 



if Measurement 
ReportReq = 1 



if PeriodReport 
expired 



Diagram 15: MSC for transmission of the measurement report 
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The parameter periodMeasurementReportAtSpecif ic is contained in the message 
RlcMeasurementReportCriterium as shown in table 32. 

Table 32: Message for measurement report criteria 



RlcMeasurementReportCriterium : := SEQUENCE { — DL, 

periodMeasurementReportAtSpecif ic PeriodMeasurementReport -- 3 bit, 
overwrites periodMeasurementReportGBI 

} 

PeriodMeasurementReport ::= INTEGER { 

usePeriodicMeasurementReportGBI (0) , 

— only for periodMeasurementReportAtSpecif ic in 
RlcMeasurementReportCriterium, 

— but not for 

— periodMeasurementReportGBI in 
RlcGeneralBroadcast Information 

period050 (1), — 50 ms 

periodlOO (2) , — 100 ms 

periodl50 (3) , -- 150 ms 

period200 (4) , — 200 ms 

noPeriodicReports (5) 

} 



The measurement report shall be transmitted in a short or long MAC signalling PDU. It shall be transmitted only when 
the AT receives a grant but not in the bandwidth contention window. Real-time traffic shall have a higher priority than 
the report. 

11.3.4 Change of downlink PHY mode 

The change of the DL PHY mode can be initiated by AT or AP. Both possibilities shall be supported. More exactly, the 
DL PHY mode referred to in the following MAC management messages is the current highest PHY mode that shall be 
monitored by the AT, i.e. the AT shall decode all PHY mode regions between the most robust PHY mode and the 
highest current PHY mode. 

For the AT initiated DL PHY mode change, the AT measures the C/(N + I) ratio of the received DL signal (which is 
also forwarded to the AP in the measurement report). The AT knows the C/(N + I) thresholds that have been 
broadcasted to all ATs in the PHY mode set descriptor section of the GBI message (for all PHY modes of the current 
PHY mode set and the thresholds are different for increasing or decreasing channel quality). 

The AT can issue a request for the DL PHY mode change by transmitting the measurement report 
RlcMeasurementReportData as described in table 31.The request is based on the CnrMeasured value and 
explicitly stated by downlinkPhyModeWanted, where the value noNewPhyMode shall not be used in this context. 

The AP sends a confirmation of the DL PHY mode change request in the DL in form of an announcement 
rlcDownlinkPhyModeChange and an acknowledgement of this announcement is sent in the UL with the message 
rlcDownlinkPhyModeChangeAck. These two messages are shown in table 33. It should be noted that the content 
of these two messages is identical but the messages appear in different contexts. 
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Table 33: Messages for DL PHY mode change request 



RlcDownlinkPhyModeChange ::= SEQUENCE { — DL for AP or AT initiated change 

downlinkPhyModeGranted DownlinkPhyMode — 3 bit 

} 

RlcDownlinkPhyModeChangeAck ::= SEQUENCE { — UL for AP or AT initiated change 

downlinkPhyModeGrantedAck DownlinkPhyMode -- 3 bit 

} 

DownlinkPhyMode ::= ENUMERATED { — 3 bit 

noNewPhyMode (0), 
downlinkPhyModel (1), 
downlinkPhyMode2 (2), 
downlinkPhyMode3 (3) , 

downlinkPhyMode4 (4), 
downlinkPhyModeFutureReserved ( 7 ) 

} 



For the order of the messages two cases have to be distinguished: 

• Changing to a more robust PHY mode as shown in diagram 16 (AT initiated) and diagram 18 (AP initiated): 
The PHY mode switching should be performed as soon as possible after reception of 
RlcMeasurementReportData and shall be done before the transmission or reception of 

RlcDownlinkPhyModeChange and RlcDownlinkPhyModeChangeAck . 

• Changing to a more efficient PHY mode as shown in diagram 17 (AT initiated) and diagram 19 (AP initiated): 
The PHY mode switching shall be performed after the reception of RlcMeasurementReportData and 
RlcDownlinkPhyModeChange and RlcDownlinkPhyModeChangeAck. 

Except for the RlcMeasurementReportData message in the UL for AT initiated DL PHY mode change, the two 
subsequent messages RlcDownlinkPhyModeChange and RlcDownlinkPhyModeChangeAck are identical for 
AT or AP initiated DL PHY mode change. 

For the AT initiated DL PHY mode changes, the whole procedure is only performed if DownlinkPhyMode = New, 
since the report RlcMeasurementReportData is also sent in other situations with 

DownlinkPhyMode = noNewPhyMode. (However, even a reception of RlcMeasurementReportData with 
DownlinkPhyMode = noNewPhyMode can stimulate the AP to command a DL PHY mode change.) 

After transmission of cRIDownlinkPhyModeChange in DL, the reception of 

RlcDownlinkPhyModeChangeAck is controlled with the timer T_DownlinkPhyModeChange. If this timer 
expires then RlcDownlinkPhyModeChange shall be repeated. 

After transmission of RlcMeasurementReportData in UL with DownlinkPhyMode = New, the reception of 
RlcDownlinkPhyModeChange is controlled with the timer T_MeasurementReportData. If this timer 
expires then RlcMeasurementReportData shall be repeated. 

If the AT receives RlcDownlinkPhyModeChange (maybe without having sent 
RlcMeasurementReportData), the AT shall reply with RlcDownlinkPhyModeChangeAck . 
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Diagram 16: MSC for AT initiated DL PHY mode change (to a more robust mode) 
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Diagram 17: MSC for AT initiated DL PHY mode change (to a more efficient mode) 
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Diagram 18: MSC for AP initiated DL PHY mode change (to a more robust mode) 
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Diagram 19: MSC for AP initiated DL PHY mode change (to a more efficient mode) 

The use of PhyThresholdPair (contained in the GBI message) consisting of the two thresholds upThreshold 
and downThreshold for the measured C/(N + I) ratio of the received DL signal is shown in figure 45. 
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Figure 45: Exemplary illustration of the dynamic behaviour of adaptive DL PHY mode change 
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1 1 .3.5 Automatic Uplink Transmit Power Control (UL ATPC) and 
Automatic Uplink Transmit Time Control (UL ATTC) 

The maximum UL transmit power of the AT is handled as follows: The maximum UL transmit power for initial ranging 
is broadcasted with the parameter uplinkPowerMaxRangingStart in the GBI message. The AT informs the AP 
about its maximum UL transmit power for QPSK and 16QAM in the RlcAtPhyCapabilitiesInf o message and 
the AP sets the limit in the RlcAtPhyCapabilitiesCnf message and can restrict the maximum UL transmit 
power furthermore with the RlcUplinkCorrection message. 

From the received UL signal the AP can derive information about necessary corrections of UL transmit power and 
transmit timing for each AT. The AT-specific DL message RlcUplinkCorrection for ATPC and ATTC is 
specified in table 34. 

The UL transmit power correction step shall be limited to ±4 dB for the regular operation. For ranging, the correction 
step shall be in the interval [-20, +4] dB to allow for fast power reductions in case of using ranging grants after link 
interruptions. The granularity is 0,5 dB in any case. 



Table 34: Message for UL transmit power and transmit timing correction 



RlcUplinkCorrection 
uplinkPower Inc 
timingAd just Fine 
measurementReportReq 

} 


: := SEQUENCE { 
UplinkPowerlnc, 
TimingAd justFine, 
MeasurementReportReq 


— DL 

— 6 bit 

— 5 bit 

— 1 bit 


RlcUplinkPowerCorrection ::= SEQUENCE { 
uplinkPowerlnc UplinkPower Inc 

} 


— DL 

— 6 bit 


RlcUplinkTimingCorrection ::= SEQUENCE { 
timingAd justFine TimingAd justFine - 

} 


— DL 

— 4 bit 


UplinkPowerlnc 


: := INTEGER (0 . . 64) 


6 bit , granu=0 , 5dB, 
— range=[-20,+4]dB 


TimingAd justFine 


: := INTEGER (0 . .16) 


— 5 bit, granu=0, 25*symbol, 

— range= [-2 , +2 ] symbols 


MeasurementReportReq ::= ENUMERATED { 
measurementReportRequestedNo (0) , 
measurementReportRequestedYes ( 1 ) 

} 





The MSC for UL transmit power and transmit timing is shown in diagram 20. The reception of 

RlcUplinkCorrection with MeasurementReportReq = measurementReportRequestedYes shall 
be acknowledged by the AT with the measurement report RlcMeasurementReportData (by using the next 
granted short MAC signalling PDU after a minimum time of 4 frames as described in clause 8.7.4) where the 
parameters refer to the new AT settings. The reception of the measurement report at AP is controlled with the timer 
T_UplinkCorrection. If this timer expires then RlcUplinkCorrection shall be repeated in DL. 

In this case, usually DownlinkPhyModeWanted = noNewPhyMode can be expected in 

RlcMeasurementReportData, but in case of DownlinkPhyModeWanted = new the AT initiated DL PHY 
mode change procedure shall be performed. 

If periodic measurement reports are requested by the AP, then the report cycle shall not be affected by additional 
intervening reports (i.e. the report period shall not be reset after transmission of a measurement report as a consequence 
of the RlcUplinkCorrection message). 
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Diagram 20: MSC for Correction of AT's transmit parameters 



1 1 .3.6 Automatic Downlink Transmit Power Control (DL ATPC) 

DL ATPC is an optional feature (to fulfil regulatory requirements if applicable) of HA systems. 

The DL transmit power in AP can be changed for the complete sector without any messaging or notification of the ATs 
in advance. The following rules are mandatory for the AP: 

• The DL transmit power shall be increased only if the current DL transmit power is not high enough for at least 
one AT in the most robust PHY mode, i.e. only after exploiting the adaptive PHY mode procedure. 

• The DL power correction shall be applied immediately before the frame preamble. 

• The DL power correction step shall not exceed 1 dB per 50 ms and 1 dB per step. 

All other features of DL ATPC are implementation-specific and thus out of the scope of the present document. 
However, it is recommended to combine DL ATPC with periodic measurement reports, to allow for a DL ATPC 
algorithm at the AP that is based on the received power measurements at the ATs. 
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The use of the first PhyThresholdPair in PhyThresholdsList (contained in the GBI message) consisting of 
the two thresholds upThreshold and downThreshold for the measured C/(N + I) ratio of the received DL signal 
is shown in the lower parts of figure 46. 



Mode 4 




£53 
< 




Time 



Figure 46: Exemplary illustration of the dynamic behaviour of DL ATPC 

NOTE: The dynamic behaviour of DL ATPC shown in figure 46 is just an example. However, the DL transmit 
power correction steps shall be small enough to guarantee that the resulting steps in C/(N + 1) are smaller 
than the gap between the two lower thresholds. (Otherwise the following situation is possible: after a DL 
power correction step C/(N + I) will be always above the upper threshold of the lower threshold pair. If 
the channel improves now immediately, then the DL power will not be reduced before crossing the 
thresholds between mode #1 and mode #2.) 



1 1 .4 Change of PHY Mode Set 

The PHY mode set descriptor (PSD) is part of the GBI message which is broadcasted from time to time (e.g. after some 
seconds, however, a strict period is not required). The GBI message is also used during the initialization process as 
described in clause 10. The PSD carries: 



• the C/(N + I) thresholds for the received and decoded DL signal; 

• the required changes of the UL transmit power in case of changing the UL PHY mode; 

• for all PHY modes within the current PHY mode set. 

A switch from one PHY mode set to another PHY mode set shall be supported (both for DL and UL RF carriers in case 
of FDD mode), where this appears only occasionally (e.g. after hours or months). The AP (or the NMS) shall initiate the 
change where the algorithms or criteria in the AP are implementation-specific and thus not specified. However, the 
procedure for the switch is specified and shown in figure 47. 

The change of the PHY mode set requires no kind of UL communication and it is possible to perform this in a 
synchronized manner for all RF channels of a sector, so that it is possible to guarantee always the same PHY mode set 
for all RF channels of a sector (however, this is not a requirement for the load-levelling feature). 
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Legend: Control zone DLorULdata 



Figure 47: Change of PHY mode set 

The procedure for switching from PHY mode set x to PHY mode set y requires that both sets are broadcasted over a 
certain period before the switching time (except for this "transition period" only one set is always contained in the GBI 
message). The GBI message with both modes is transmitted several times (e.g. 2. ..4 times) to guarantee with a very high 
probability that all ATs receive this information correctly at least once. Each set is uniquely referenced to by a PSDI 
(PSD indicator), which is contained in the GBI message as shown in table 23. A length of 4 bits for the PSDI field 
allows in theory to manage up to 16 different PHY mode sets. The PSDI field is contained in each control zone as 
shown in figure 29, so a switch from set x to set y can be commanded with immediate effect by switching the PSDI 
field from x to y. 

The frequency of the GBI message and the number of PSD repetitions for the transition period can be selected by the 
AP. 

For the transition phase from PHY mode set x to PHY mode set y, the following recommendations should be observed: 

• A change of the mode number in the UL is not recommended (e.g. from mode 2 of set x to mode 3 of set y), 
since the necessary power correction step is unknown to the ATs. 

• It is recommended to switch all ATs (in DL and UL) to the most robust mode #1 before the transition phase 
(since modes #1 of PHY mode sets x and y are identical, the UL transmit power of all ATs does not need any 
corrections after the change). 

• PHY mode change procedures should be avoided during the transition phase. 

1 1 .5 Change of UL structure 

As defined in clause 5.2.6 and figure 13, the following two features can be switched on/off for the UL direction: 

• None to several midambles per FEC block. 

One MAC PDU per FEC block. 

Both features are handled on a per carrier basis (i.e. identical for all ATs) and can be time-variant (i.e. can change on a 
frame -by-frame basis). Each feature is broadcasted to all ATs by one bit in the GBI message as shown in table 23. 
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1 1 .6 Load levelling (inter-carrier handover) 

Load levelling means the switching from one RF channel (i.e. pair of RF carriers for DL and UL communication in case 
of FDD) to another RF channel, where this shall be initiated by the NMS (Network Management System) or by the AP. 

In order to avoid unnecessary complexity, a fast dynamic load levelling procedure is not supported. The PHY layer 
needs about 100 ms for changing the carrier frequencies, so a seamless load-levelling is not possible (with only one 
transceiver per AT). 

The specified load levelling procedure means basically that an AT shall be switched off from the old RF channel and 
shall perform a new first initialization procedure on the new RF channel. All parameters settings are commanded and 
negotiated again, i.e. an information exchange between the two APTs is not required. 

The implementation of load levelling is optional for AP and mandatory for AT. 

The details of the load levelling procedure are described in table 35 and diagram 21. The load levelling command 
RlcHandoverCmd contains a description of the new RF channel (and the AT MAC Address) and no other 
information. The AT shall reply with the message RlcHandoverAck and then the new APT is informed from the old 
APT to start the initialization process by issuing the RlcRanginglnvitation message. All parameter setting at the 
AT are cancelled and new established as for a first initialization. 



Table 35: Messages for load levelling 



RlcHandoverCmd ::= SEQUENCE { 

atMacAddress AtMacAddress, - - 
newPairOf CarrierFrequencies PairOf CarrierFrequencies 
apcld Apcld 


DL 

48 bit 
34 bit 
24 bit } 


RlcHandoverAck ::= 
atMacAddress 

} 


SEQUENCE { 

AtMacAddress 


DL 

48 bit 


AtMacAddress ::= 


OCTET STRING (SIZE (6)) 




PairOf CarrierFrequencies ::= 
uplinkCarrierFrequency 
downlinkCarrierFrequency 

} 


SEQUENCE { 

CarrierFrequency, 
CarrierFrequency 

equal to uplinkFrequency for TDD 


CarrierFrequency ::= INTEGER ( 1 .. 130000 ) — 17 bit, granu=0,5 


MHz, range=[0,65] GHz 


Apcld ::= INTEGER(1 .. 16777216) 
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Diagram 21 : MSC for load levelling 
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12 Security control 

12.1 Operational overview 
12.1.1 Privacy initialization 

Authentication and privacy establishment shall be part of the AT initialization process. During the initial ranging 
process, the AP has been assigned the basic, primary and secondary MAC management connections to the AT. The AT 
shall use the primary management connection ID to exchange the security control messages with the AP. 

Privacy initialization begins with the AP sending the AT an authentication command (RlcAuthCmd) message. The AT 
shall reply with the authentication information (RlcAuthManufacturerlnfo) and an authorization request (RlcAuthReq) 
message. If the AP determines the requesting AT is authorized, the AP shall respond with an Authorization Reply 
(RlcAuthReply) message containing the authorization key AK, which shall be used to encrypt the AT's traffic 
encryption key (TEK). The AP shall encrypt the AK with the receiving AT's public key. 



AP 



AT 



Privacy 
Initialization 



Traffic Encryption 
Key 



Primary management connection 









Authentication Command 

Authentication Information 
Authorization Request 

Authorization Reply 

(Authorization Key (AK) 
encrypted with AT's public key, one 
SAID) 



Requesting Traffic Enc. Key (TEK) 
Providing Traffic Enc. Key (TEK) 



AT authentication 
and authorization 



completed 
successfully 



encrypted with AK 



Figure 48: Illustration of the authentication and privacy initialization 

After successfully completing authentication and authorization with the AP, the AT shall request a traffic encryption 
key for the Security Association IDentity (SAID) received together with the AK in the RlcAuthReply message. 
Therefore, the AT shall send a TEK Request (RlcTekReq) message to the AP. The AP shall respond with two TEK 
Allocation (RlcTekAllocation) messages, each containing one TEK, which is triple DES encrypted, 
i.e. Encrypt-Decrypt-Encrypt (EDE) mode, with the AK. Each TEK has a lifetime which is given together with the TEK 
and the assigned TEK sequence number. The TEK sequence number is used to synchronize the switch over from one 
TEK to the other. 

The security overview figure below illustrates the different sequences. The left path of authentication and 
First Tek Allocation shall be used after first initialization. In case of re-initialization, supposing that AK and TEKs are 
not expired, the authentication and First Tek Allocation procedures shall not be applied. As AK has a limited lifetime 
the new AK shall be provided performing re-authentication. There exists also a lifetime for the TEK, therefore the TEK 
shall be refreshed using the TEK refresh allocation procedure. In case that the expiration time for AK and TEK match, 
the re-authentication procedure shall be used before the TEK Refresh Allocation. 
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Figure 49: HMSC for security overview 



12.1.2 AT Key update mechanism 

The TEKs, which the AP provides to its ATs, have a limited lifetime. The AP delivers a key's remaining lifetime, along 
with the key value, in the TEK Allocation message it sends to its AT. The AP controls which keys are current by 
flushing expired keys and generating new keys. It is the responsibility of individual ATs to insure the keys they are 
using match those the AP is using. ATs do this by tracking when a particular TEK is scheduled to expire and issuing a 
new TEK Request (RlcTekReq) message for the latest key prior to that expiration time. 

In addition, ATs are required to periodically re-authorize with the AP. As is the case with TEKs, an AK has a finite 
lifetime, which the AP provides the AT along with the key value. It is the responsibility of each AT to re-authorize and 
obtain a fresh AK before the AP expires the AT's current AK. 
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1 2.1 .3 PKM key management messages 

The PKM key management messages are summarized in table 36. 



Table 36: PKM key management messages 



PKM Message 


Description 


RIcAuthCmd 


The Authentication command message sent from the AP to the AT starts the first 
authentication process after first initialization. 


RIcAuthManufacturerlnfo 


The RIcAuthManufacturerlnfo message is transmitted from the AT to the AP and contains 
the AT manufacturer's X.509 Certificate, issued by an external authority. 


RIcAuthReq 


An Authorization Request message is sent from an AT to its AP to request an AK and one 
SAID. The AT provides the AT X.509 certificate, manufacturer ID and the ATs public key. 


RIcAuthReply 


An Authorization Reply message is sent from an AP to an AT to reply an AK, AK lifetime 
and sequence number and an SAID. 


RIcAuth Reject 


An Authorization Reject message is send from an AP to an AT in rejection of an 
Authorization Request message sent by the AT. 


RIcAuthlnvalid 


An Authorization Invalid message is send from an AP to an AT as an unsolicited indication 
or a response to a message received from that AT. 


RIcTekReq 


A TEK Request message is sent from an AT to its AP requesting a TEK for the privacy of its 
authorized SAID. 


RIcTekAllocation 


A TEK Allocation message is sent from an AP to an AT carrying one traffic encryption 
keying material for the SAID. 


RIcTekRejct 


A TEK Reject message is sent from an AP to an AT indicating that the SAID is no longer 
valid and no key will be sent. 


RIcTeklnvalid 


A TEK Invalid message is sent from an AP to an AT if it determines that the AT encrypted 
uplink traffic with an invalid TEK. 



1 2.2 Privacy key management protocol 

This clause contains the details of the PKM protocol, which is specified by two separate, but interdependent, Finite 
State Machines (FSMs): the Authorization FSM and the TEK FSM. Communication between the Authorization FSM 
and TEK FSM occurs through the passing of events and protocol messaging. The Authorization FSM generates events 
(i.e. Stop, Authorized, Authorization Pending, and Authorization Complete events) that are targeted at its child TEK 
FSMs. TEK FSMs do not target events at their parent Authorization FSM. The TEK FSM affects the Authorization 
FSM indirectly through the messaging that an AP sends in response to an AT's requests. For example, an AP may 
respond to a TEK machine's Key Request messages with an Authorization Invalid message that shall be handled by the 
Authorization FSM. 

The rest of this clause describes the AT authorization and defines the two FSMs. These FSMs shall be used as the 
definitive specification of protocol actions associated with each state transition. 

12.2.1 AT authorization 

AT authorization, controlled by the Authorization FSM, contains the process of: 

• the AP authenticating a client AT's identity, 

• the AP providing the authenticated AT with an AK, and 

• the AP providing the authenticated AT with the SAID that the AT is authorized to obtain keying information 
for. 

After achieving initial authorization, an AT periodically seeks re- authorization with its AP, which is also managed by 
the AT's Authorization FSM. An AT shall maintain its authorization status with the AP in order to be able to refresh 
aging TEKs, which are managed by TEK FSMs. 
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12.2.1.1 



Initial authorization 



An AT shall begin authorization as soon as it is invited with an RlcAuthCmd message from the AP (see diagram 22). 
The AT shall reply with an RlcAuthManufacturerlnfo message to its AP. The RlcAuthManufacturerlnfo message 
contains the AT manufacturer's X.509 certificate, issued by an external authority. The 

RlcAuthManufacturerlnfomessage shall be strictly informative, i.e. the AP may choose to ignore it. However it does 
provide a mechanism for an AP to learn the manufacturer certificates of its ATs. 
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Diagram 22: MSC for successful initial authentication 
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MSC auth Reply Lost 





AP 




AT 











no_RlcTekReq_or_old_AkSeqNo 



> 



AP selects newAK 



keep the same 
AkSeqNo 



RIcAuthReply 



(/* AuthKey, AkSeqNo, AkLifeTime, Said 7) 

RIcAuthReq 



AtX509certificate, AtPublicKey, Manufacturerld 7) 



T_AuthReq 
T_AuthReq 



Diagram 23: MSC for retransmission in case of RIcAuthReply loss 

After transmitting the RlcAuthManufacturerlnfo message the AT shall send an RIcAuthReq message to request an AK 
from its AP. The RIcAuthReq message shall include: 

• the AT's manufacturer ID, 

• the AT's public key, 

an AT X.509 certificate, 

together with the transmission of the RlcAuthCmd the AP shall set a timer (T_AuthCmd) and shall resend the 
RlcAuthCmd if it does not receive the RlcAuthManufacturerlnfo and RIcAuthReq messages before the timer expires. 

In response to an RIcAuthReq message, the AP validates the requesting AT's identity, activates an AK for the AT, 
encrypts the AK with the AT's public key, and sends the encrypted AK back to the AT in an RIcAuthReply message. 
The AT expects the RIcAuthReply message before the timer T_AuthReply is expired, otherwise the AT shall resend the 
RIcAuthReq message. The RIcAuthReply message shall include: 

• an AK encrypted with the AT's public key, 

• a 2-bit key sequence number used to distinguish between successive generations of AKs, 

• the AK's lifetime, and 

• one SAID the AT is authorized to obtain keying material for. 
After the T_AuthReply timer is expired the AP and AT can use the AK. 

If the AP, in responding to an AT's RIcAuthReq message, rejects the AT's request, the AP shall send an RlcAuthReject 
message to the AT. RlcAuthReject message shall include: 

• an error code indicating the reason for the rejection; 

• an optional text string providing reason for the rejection. 

If the error code does not indicate a permanent rejection the AT shall request for authorization again with the 
RIcAuthReq message. 
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12.2.1.2 



Reauthorization 



An AT shall periodically refresh its AK by re-issuing an RlcAuthReq message to the AP. Reauthorization is identical to 
authorization with the exception that the AT is not commanded by the AP and does not send any 
RlcAuthManufacturerlnfo message during reauthorization cycles. Clause 12.2.2 provides details on the Authorization 
FSM, which clearly indicates when RlcAuthManufacturelnfo messages are sent. 

If the AT has not received the RlcAuthReply message before the timer T_AuthReq has expired it shall generate the 
RlcAuthReq again. 

• After the AP has received the RlcAuthReq, the AP shall generate a new AK and reply with the RlcAuthReply 
as described in clause 12.2.1.1. 



MSC SC ReAuthentication 



AP 



AP rejects 
authentication of AT 
after checking certificate 



unencrypted 

primary MAC mgmt conn 



AT 



RlcAuthReq 



/* AtX509certificate, AtPublicKey, Manufacturerld 7) 



RIcAuthReject 



(/* AuthRejectErrorCode, ErrorlnfoText[Optional] 7) 



AP selects new AK 



AkSeqNo 
incremented 



T_AuthReq 



AT behaviour 
depends on 
ErrorCode 



loop <0, n> authReplyLost 



RlcAuthReply 



(/* AuthKey, AkSeqNo, AkLifeTime, Said 7) 



T_AuthReq 



AT_uses_new_AK_in_uplink_tekMessage 



RlcTekReq_with_new_AkSeqNo 



newAK used in downlink 



oldAK_shall 


_be_deleted 









oldAK_shall 


_be_deleted 









Diagram 24: MSC for re-authorization of AT before AK lifetime expiration 
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To avoid service interruptions during reauthorization, successive generations of the AT's AKs shall have overlapping 
lifetimes determined by the AK Lifetime, which is a predefined AP system configuration parameter. Both AT and AP 
shall be able to support up to two simultaneously active AKs during these transition periods. The operation of the 
Authorization FSM's Authorization Request message scheduling algorithm (see clause 12.2.2), combined with the AP's 
regimen for updating and using an AT's AKs, insures that AT be able to refresh TEK keying material without 
interruption over the course of the AT's reauthorization periods. 

1 2.2.1 .3 First key requests 

Upon achieving authorization, an AT shall start a TEK FSM for the SAID identified in the RlcAuthReply message. The 
TEK FSM operating within the AT is responsible for managing the keying material associated with its respective SAID. 
TEK FSM periodically sends RlcTekReq messages to the AP, requesting a refresh of keying material for their 
respective SAID. A RlcTekReq message shall include: 

• the SAID whose keying material is being requested. 
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MSC SC FirstTekAllocation 



< 



No TEK available 



RlcTek2Req 



(/* Said 7) 



loop <0, m> firstTekAllocationLost 



newTEK1,IVAP 
is chosen 



keep the same 
TekSeqNo 



RIcTekAllocation 



(/* Said, [TEK1] encrypted with AK, IVAP, Hmac, 
TekLifeTime, TekSeqNo, InitializationStatus 7 ) 



newTEK2,IVAP 
is chosen 



keep the same 
TekSeqNo + 1 



RIcTekAllocation 



(/* Said, [TEK2] encrypted with AK, IVAP, Hmac, 
TekLifeTime, TekSeqNo, InitializationStatus 7 ) 



AP 




AT 











> 



-X T_Tek2Req 



Check Hmac, 
InitializationStatus 
to be ignored 



Check Hmac 



-X T_Tek2Req 



Use_Tekn+1 for uplink data 



Data_in_uplink_with_Tekn+1 



Use_TEK1_for_DL_and_ 
Use TEK2 for UL 





Diagram 25: MSC for first TEK requests 



In case of re-initialization, the same diagram applies since the existing TEKs are not valid and are destroyed pending 
re-initialization. 
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MSC firstTekAllocationLost 



AP 


_ 





no_DataUp 



AT 



TeqSeqNum= n 



AP selects newTEK, 
IVAP 



TekSeqNo = 1 



RlcTekAllocation 



(/* Said , Tek encrypted with AK, IVAP, Hmac, 
TekLifeTime, TekSeqNo, InitializationStatus */ ) 



Any of the messages may be I 
received by the AT but not both 



AP selects newTEK, 
IVAP 



TekSeqNum= 

n+lmod4 use next TekSeqNum 



RlcTekAllocation 



(/* Said , Tek encrypted with AK, IVAP, Hmac, 
TekLifeTime, TekSeqNo, InitializationStatus */ ) 



RlcTek2Req 



(/*Said */) 



T_Tek2Req 
T_Tek2Req 



Diagram 26: MSC for retransmission in case of RlcTekAllocation loss during first initialization 



ETSI 



145 



ETSI TS 102 000 V1.3.1 (2002-12) 



MSC SC TekRefreshAllocation 



DurationTekReq must be 
large enough for encryption 
and transmission of TEKs 



AP 




AT 











Use_TEKn-1_for_DL_and_ 
Use TEKn for UL 



> 



Tekn-1 and Tekn 
available on both sides 



RIcTekReq 



(/* Said 7) 



RIcTekReject 



(/* TekRejectErrorCode, ErrorlnfoText[Optional] 7) 



T_TekReq 







new TEK, IVAP 
is chosen 






Result TekSeqNo 
= n+1 mod 4 




TekSeqNo 
incremented 



TEkn-1 can be deleted 



Use_TEKn_for_DL_and_ 
Use TEKn for UL 



> 



loop <0, n> tekAllocationLost 



The n+1 TekSeqNo 



< 



RIcTekAllocation 



(/* Said, [TEKn+1] encrypted with AK, IVAP, Hmac 
TekLifeTime, TekSeqNo, InitializationStatus 7 



Data_with_new_TekSeqNo 



> 



InitializationStatus 
to be ignored for 
non-initialization 



Tekn+1 available, 
Tekn-1 deleted 



Use_Tekn+1 for uplink data 



Use_TEKn_for_DL_and_ 
Use TEKn+1 for UL 



Both sides have 
Tek n and n+1 





Diagram 27: MSC for key renewal before life time expiration 



ETSI 



146 



ETSI TS 102 000 V1.3.1 (2002-12) 



MSC tekAllocationLost 





AP 




AT 











no _D ataUp_or_old_TekS eqNo 



TeqSeqNum= n 



exc TekLifeTimeExpired 



AP selects newTEK 



TekSeqNum= 
n+ 1 mod 4 



keep the same 
TekSeqNo 



RkTekAllocation 



(/* Said , Tek encrypted with AK, IV AP, Hmac, 
TekLifeTime, TekSeqNo, InitializationStatus */ ) 

RlcTekReq |7 T_TekReq 

(/•Said*/) T.TekReq 



Diagram 28: MSC for retransmission in case of RIcTekAl location loss during key renewal 

The AP shall respond to a first RlcTekReq message with two RlcTekAllocation messages containing each one keying 
material for the SAID. This keying material includes: 

the triple-DES-encrypted TEK, 

64-bit IV parameter derived from the random number, 

a 2-bit key sequence number used to distinguish between successive generations of TEKs, 
the TEK's remaining lifetime, and 

an HMAC keyed message ensuring the integrity of the RlcTekAllocation message. 

At all times the AP maintains two active sets of keying material per SAID. The two generations of the AT's TEKs shall 
have overlapping lifetimes (see clause 12.3.1) determined by the TEK Lifetime, which is a predefined AP system 
configuration parameter. The lifetimes shall overlap so that each generation becomes active halfway through the life of 
its predecessor and expires halfway through the life of its successor. This is achieved by providing the second delivered 
TEK with a longer lifetime than the TEK given by the first RlcTekAllocation message, see figure 49. 

The AP transitions between the two active TEKs happen differently -depending on whether the TEK is used for 
downlink or uplink traffic. For each of its SAIDs, the AP shall switch from old TEK to new TEK according to the 
following rules: 

• Downlink: The AP shall use the older of the two active TEKs for encrypting downlink traffic. Before the 
expiration of the older TEK, the AP shall start to use the newer TEK for encryption (see figure 50). 

• Uplink: The transition period begins from the time the AP sends the newer TEK in an RlcTekAllocation 
message and concludes once the older TEK expires. While in the transition period, the AP shall be able to 
decrypt uplink frames using either the older or newer TEK. 

Note that the AP encrypts with a given TEK for only the second half of that TEK's total lifetime. The AP is able, 
however, to decrypt with a TEK for the TEK's entire lifetime. 
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TEK (seq #0) 
TEK (seq #1) 









TEK 7 











AP 
TekAlloc. 
Message 
TEK1 

AP 
TekAlloc 

Message 
TEK2 



TEK (seq #0) U 



TEK (seq #1) 




downlink 



time 



uplink 



Used TEK for downlink or uplink encryption 
| | TEK memory content in AP or AT 

Figure 50: TEK lifetime and switch over (AT viewpoint) 

An AT shall be capable of maintaining two successive sets of traffic keying material for the authorized SAID. Through 
operation of its TEK FSMs, an AT shall attempt to always maintain two sets of traffic keying material. 

For its authorized SAID, the AT: 

• shall use the newer of its two TEKs to encrypt newly received uplink traffic (traffic already queued up may 
use either TEK for a brief period of time covering the transition from the old to the new key), and 

• shall be able to decrypt downlink traffic encrypted with either of the TEKs. 

The receiving AT uses these remaining lifetimes to estimate when the AP will invalidate a particular TEK. It then 
schedules future RlcTekReq messages so that the new keying material is requested and received before the AP expires 
the current keying material. 
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MSC SC TekRefreshAllocation 



DurationTekReq must be 
large enough for encryption 
and transmission of TEKs 



AP 
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Use TEKn for UL 



RIcTekReq 



(/* Said 7) 



RIcTekReject 



(/* Tek Reject ErrorC ode, ErrorlnfoText[Optional] 7 
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Result TekSeqNo TekSeqNo 
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TEkn-1 can be deleted 



U se_TE Kn_f o r_ D L_an d_ 
Use TEKn for UL 
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The n+1 TekSeqNo 





RIcTekAllocafon 


) 




(/* Said, [TEKn+1] encrypted with AK, IVAP, Hmac, 
TekLifeTime, TekSeqNo, InitializationStatus 7 




Use_Tekn+1 for uplinkdata 
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Both sides have 
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Diagram 29: MSC for TEK re-requesting due to loss of key request or key reply message 

The operation of the TEK FSM's Key Request message scheduling algorithm, combined with the AP's regimen for 
updating and using an SAID's keying material (see clause 12.3.1), insures that the AT will be able to continually 
exchange encrypted traffic with the AP. 

A TEK FSM shall remain active as long as the AT has a valid AK and the AP continues to provide fresh keying 
material during re-key cycles. The parent Authorization FSM shall stop all of its child TEK FSMs when the AT 
receives from the AP an RlcAuthReject message during a reauthorization process. 



1 2.2.2 Authorization finite state machine 

The Authorization FSM consists of six states and eight distinct events (including receipt of messages) that trigger state 
transitions. The Authorization FSM is presented below in a graphical format, as a state flow diagram (see figure 51), 
and in a tabular format, as a state transition matrix (see table 37). 
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The state flow diagram depicts the protocol messages transmitted and internal events generated for each of the state 
transitions. However, the diagram does not indicate additional internal actions, such as the clearing or starting of timers, 
which accompany the specific state transitions. Accompanying the state transition matrix is a detailed description of the 
specific actions accompanying each state transition. The state transition matrix shall be used as the definitive 
specification of protocol actions associated with each state transition. 

The following legend applies to the FSM flow diagrams depicted in figure 49 and figure 50. 

• Ovals are states. 

• Events are in italics. 

• Messages are in normal font. 

• State transitions (i.e. the lines between states) are labelled with <what causes the transition>/<messages and 
events triggered by the transition>. So "timeout/ Auth Request" means that the state received a "timeout" event 
and sent an Authorization Request message. If there are multiple events or messages before the slash "/" 
separated by a comma, any of them can cause the transition. If there are multiple events or messages listed 
after the slash, all of the specified actions must accompany the transition. 



■ Timeout I- 
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RIcAuthReq 
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y 



Timeout I 
RIcAuthReq 
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Figure 51 : Authorization finite state machine flow diagram (AT side) 



The Authorization state transition matrix presented in table 37 lists the six Authorization FSM states as the columns and 
the eight Authorization FSM events (includes message receipts) as rows. Any cell within the matrix represents a 
specific combination of a state and an event, with the next state (the state transitioned to) displayed within the cell. For 
example, cell 4-B represents the receipt of an Authorization Reply message when in the Authorize Wait state. Within 
cell 4-B is the name of the next state, "Authorized." Thus, when an AT's Authorization FSM is in the Authorize Wait 
state and an Authorization Reply message is received, the Authorization FSM shall transition to the Authorized state. In 
conjunction with this state transition, several protocol actions shall be taken; these are described in the listing of 
protocol actions, under the heading 4-B, in clause 12.2.2.5. 
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Table 37: Authorization FSM state transition matrix 



State 
Event or Rcvd 
msg 


(A) 
Starting 


(B) 
Auth Wait 


(C) 
Authorized 


(D) 
Reauth 
Wait 


(E) 

Auth Reject 
Wait 


(F) 
Terminate 
FSM 


(1) 

RIcAuthCmd 


Auth Wait 












(2) 

RIcAuth Reject 
(non-perm) 




Auth Reject Wait 




Auth Reject 
Wait 






(3) 

RIcAuth Reject 
(perm) 




Silent 




Silent 






(4) 

RIcAuth Reply 




Ai ithnri7Prl 




Ai ithnri7Prl 

nu Li iui 






(5) 

T A i ithDon 

i MUinneq 




Auth Wait 




Reauth Wait 


Starting 




(6) 

T AuthGrace 






Reauth Wait 








(7) 

RIcAuthlnvalid 






Reauth Wait 


Reauth Wait 






(8) 
ReAuth 






Reauth Wait 








(9) 

T_Auth Reply 















A shaded cell within the state transition matrix implies that either the specific event cannot or should not occur within 
that state and that if the event does occur the FSM shall ignore it. For example, if an Authorization Reply message 
arrives when in the Authorized state (see cell 4-C), that message shall be ignored. The AT may, however, in response to 
an improper event, log its occurrence, generate an SNMP event, or take some other vendor-defined action. These 
actions, however, are not specified within the context of the Authorization FSM, which shall simply ignore improper 
events. 

12.2.2.1 States 

Start: This is the initial state of the FSM. No resources are assigned to or used by the FSM in this state, i.e. all timers are 
off and no processing is scheduled. The AT waits for an RIcAuthCmd from the AP. 

Authorize Wait (Auth Wait): The AT receives the RIcAuthCmd message indicating that it can start with the first 
authorization. In response to receiving the message, the AT shall send an RlcAuthManufacturerlnfo message and an 
RlcAuthReq message to the AP and shall wait for a response. 

Authorized: The AT receives an RlcAuthReply message, which contains a SAID for this AT. At this point, the AT has a 
valid AK and SAID. Transition into this state shall trigger the creation of a TEK FSM for the AT's privacy-enabled 
SAIDs. 

Reauthorize Wait (Reauth Wait): The AT has an outstanding reauthorization request. The AT either is about to time out 
its current authorization or has received an indication (i.e. an Authorization Invalid message from the AP) that its 
authorization is no longer valid. The AT shall send an RlcAuthReq message to the AP and shall wait for a response. 

Authorize Reject Wait (Auth Reject Wait): The AT receives an RlcAuthReject message in response to its last 
RlcAuthReq message. The RlcAuthReject message's error code indicated the error is not of a permanent nature. In 
response to receiving this reject message, the AT shall set a timer and shall transition to the Authorize Reject Wait state. 
The AT shall remain in this state until the timer expires. 

Terminate FSM: The AT received an RlcAuthReject message in response to its last RlcAuthReq message. The 
RlcAuthReject message's error code indicated the error is of a permanent nature. This shall trigger a transition to the 
Terminate FSM state, where the AT is not permitted to pass subscriber traffic. 
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12.2.2.2 Messages 

Authentication Command (RlcAuthCmd): This message commands the AT to start the authentication and authorization 
process. 

Authentication Information (rlcAuthManufacturerlnfo): The Authentication Information message contains the AT 
manufacturer's X.509 Certificate, issued by an external authority. The Authentication Information message is strictly an 
informative message the AT sends to the AP. With an Authentication Information message, an AP may dynamically 
learn the manufacturer certificate of an AT. Alternatively, an AP may require out-of-band configuration of its list of 
manufacturer certificates. 

Authorization Request (RlcAuthReq): Sent from an AT to its AP to request an AK and the authorized SAID. 

Authorization Reply (RlcAuthReply): Sent from an AP to an AT to reply an AK and an authorized SAID. The AK is 
encrypted with the AT's public key. 

Authorization Reject (RlcAuthReject): Sent from an AP to an AT in rejection of an Authorization Request message sent 
by the AT. The error code in the Authorization Reject message indicates the error. If the indicated error is of type 
"permanentRejection" this error should be subject to administrative control within the AP. Authorization Request 
message processing errors that can be interpreted as permanent error conditions may include: 

• unknown manufacturer (do not have Certification Authority certificate of the issuer of the AT Certificate); 

• invalid signature on AT certificate. 

When an AT receives an Authorization Reject message indicating a permanent failure condition, the Authorization 
FSM moves into a TerminateFSM state where the AT is not permitted to pass Subscriber traffic. The AT shall, 
however, respond to MAC management messages from the AP issuing the Authorization Reject message. 

If the indicated error in the RlcAuthReject is of type "reAuthorizationRequested" sent from an AP to an AT in rejection 
of an Authorization Request the error is not of a permanent nature. As a result, the AT's Authorization FSM shall set a 
wait timer and transition into the Authorization Reject Wait State. The AT shall remain in this state until the timer 
expires, at which time it may re-attempt authorization. 

Authorization Invalid (RlcAuthlnvalid): The AP may send an RlcAuthlnvalidmessage to an AT as: 

1) an unsolicited indication, or 

2) a response to a message received from that AT. 

In either case, the RlcAuthlnvalidmessage instructs the receiving AT to reauthorize with the AP. The AP shall respond 
to a Key Request message with an Authorization Invalid message if (1) the AP does not recognize the AT as being 
authorized (i.e. no valid AK associated with AT) or (2) verification of the RlcTekRequest message's keyed message 
digest (in HMAC-Digest Attribute) failed. Note that the Authorization Invalid event, referenced in both the state flow 
diagram and the state transition matrix (FSM), signifies either the receipt of an RlcAuthlnvalid message or an internally 
generated event. 

12.2.2.3 Configuration parameters 

If Privacy is enabled, all Privacy configuration parameters shall be present and shall be supported by all ATs. 

Authorize Wait Timeout: Timeout period between sending of two consecutive Authorization Request messages from 
Authorize Wait state. 

Reauthorize Wait Timeout: Timeout period between sending of two consecutive Authorization Request messages from 
Reauthorize Wait state. 

Authorization Grace Time: Amount of time before authorization is scheduled to expire that the AT starts 
reauthorization process. 

Authorize Reject Wait Timeout: Amount of time an AT's Authorization FSM remains in the Authorize Reject Wait 
state before transitioning to the Start state. 
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12.2.2.4 Events 

Timeout: A retransmission or wait timer timed out. Generally a request is resent. 

Authorization Grace Timeout (Auth Grace Timeout): The Authorization Grace timer times out. This timer fires a 
configurable amount of time (the Authorization Grace Time) before the current authorization is supposed to expire, 
signalling the AT to reauthorize before its authorization actually expires. 

Authorization Invalid (Auth Invalid): This event can be internally generated by the AT when there is a failure 
authenticating an RlcTekReplymessage or RlcTekReqmessage. It can also be externally generated by the receipt of an 
RlcAuthlnvalidmessage sent from the AP to the AT. An AP shall respond to an RlcTekReqmessage with an 
RlcAuthlnvalidmessage if verification of the request's message authentication code fails. Both cases indicate AP and 
AT have lost AK synchronization. An AP may also send an unsolicited RlcAuthlnvalidmessage to an AT, forcing an 
RlcAuthlnvalidevent. 

NOTE: the following events are sent by an Authorization FSM to its child TEK FSMs. 

[TEK] Stop: Sent by the Authorization FSM to an active (non-Start state) TEK FSM to terminate the FSM and remove 
the corresponding SAID keying material from the AT's key table. 

[TEK] Authorized: Sent by the Authorization FSM to a non-active (Start state), but valid TEK FSM. 

[TEK] Authorization Pending (Auth Pend): Sent by the Authorization FSM to a specific TEK FSM to place that TEK 
FSM in a wait state until the Authorization FSM can complete its reauthorization operation. 

[TEK] Authorization Complete (Auth Comp): Sent by the Authorization FSM to a TEK FSM in the Operational 
Reauthorize Wait (Op Reauth Wait) or Rekey Reauthorize Wait (Rekey Reauth Wait) state to clear the wait state 
triggered by a [TEK] Authorization Pending event. 

12.2.2.5 Actions 

Actions taken in association with state transitions are listed by <event/rcvd message>-<state> below: 

1- A received RlcAuthCmd message, transition from Start to Auth Wait: 

• send an RlcAuthManufacturerlnfo message to the AP, 

• send an RlcAuthReq message to the AP, 

• set the RlcAuthReq retry timer to Authorize Wait Timeout. 

2- B received RlcAuthReject (non-perm) message, transition from Auth Wait to Auth Reject Wait: 

• clear Authorization Request retry timer, 

• set a wait timer to Authorize Reject Wait Timeout. 

2- D received RlcAuthReject (non-perm) message, transition from Reauth Wait to Auth Reject Wait: 

• clear RlcAuthReq retry timer, 

• generate TEK Stop events for all active TEK FSMs, 

• set a wait timer to Authorize Reject Wait Timeout. 

3- B received RlcAuthReject () message, transition from Auth Wait to TerminateFSM state: 

• clear RlcAuthReq retry timer, 

• disable all forwarding of AT traffic. 
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3- D received Auth Reject (permanentRejection) message, transition from Reauth Wait to Silent: 

• clear RlcAuthReq retry timer, 

• generate TEK Stop events for all active TEK FSMs, 

• disable all forwarding of AT traffic. 

4- B received RlcAuthReply message, transition from Auth Wait to Authorized: 

• clear Authorization Request retry timer, 

• decrypt and record AK delivered with RlcAuthReply message, 

• start TEK FSMs for all SAIDs listed in RlcAuthReply message and issue a TEK Authorized event for each of 
the new TEK FSMs, 

• set the Authorization Grace timer to go off "Authorization Grace Time" seconds prior to the supplied AK's 
scheduled expiration time. 

4- D received Auth Reply message, transition from Reauth Wait to Authorized: 

• clear Authorization Request retry timer, 

• decrypt and record AK delivered with RlcAuthReply message, 

• generate a TEK Authorization Complete event for each currently active TEK FSM whose corresponding 
SAIDs are listed in Authorization Reply message, 

• generate a TEK Stop event for each currently active TEK FSM whose corresponding SAID are not listed in 
Authorization Reply message, 

• set the Authorization Grace timer to go off "Authorization Grace Time" seconds prior to the supplied AK's 
scheduled expiration time. 

5- B received Timeout event, transition from Auth Wait to Auth Wait: 

• send RlcAuthManufacturerlnfo message to the AP, 

• send RlcAuthReq message to the AP, 

• set Authorization Request retry timer to Authorize Wait Timeout. 
5-D received Timeout event, transition from Reauth Wait to Reauth Wait: 

• send RlcAuthReq message to the AP, 

• set RlcAuthReq retry timer to Reauthorize Wait Timeout. 

5- E received Timeout event, transition from Auth Reject Wait to Start: 

• no protocol actions associated with this state transition. 

6- C received Auth Grace Timeout event, transition from Authorized to Reauth Wait: 

• send RlcAuthReq message to the AP, 

• set RlcAuthReq retry timer to Reauthorize Wait Timeout. 
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7-C received Auth Invalid event, transition from Authorized to Reauth Wait: 

• clear Authorization Grace timer, 

• send RlcAuthReq message to the AP, 

• set RlcAuthReq retry timer to Reauthorize Wait Timeout, 

• if the Authorization Invalid event is associated with a particular TEK FSM, generate a TEK FSM 
Authorization Pending event for the TEK FSM responsible for the Authorization Invalid event (i.e. the TEK 
FSM that either generated the event, or sent the Key Request message the AP responded to with an 
Authorization Invalid message). 

7- D received Auth Invalid event, transition from Reauth Wait to Reauth Wait: 

• if the Authorization Invalid event is associated with a particular TEK FSM, generate a TEK FSM 
Authorization Pending event for the TEK FSM responsible for the Authorization Invalid event (i.e. the TEK 
FSM that either generated the event, or sent the Key Request message the AP responded to with an 
Authorization Invalid message), 

8- C received Reauth event, transition from Authorized to Reauth Wait: 

• clear Authorization Grace timer, 

• send RlcAuthReq message to the AP, 

• set RlcAuthReq retry timer to Reauthorize Wait Timeout. 
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1 2.2.3 TEK Finite State Machine 

The TEK FSM consists of seven states and nine events (including receipt of messages) that may trigger state transitions. 
Like the Authorization FSM, the TEK FSM is presented in both a state flow diagram (see figure 52) and a state 
transition matrix (see table 38). And as was the case for the Authorization FSM, the state transition matrix shall be used 
as the definitive specification of protocol actions associated with each state transition. 



Stopl- 




Timeoutl 
RIcTekReq 

J 



Figure 52: TEK Finite State Machine Flow Diagram 



Heavily shaded states in figure 52 (i.e. Operational, Rekey Wait, and Rekey Reauthorize Wait states) have valid keying 
material and encrypted traffic may be transmitted. 

The Authorization FSM starts an independent TEK FSM for the authorized SAID. 

As mentioned previously in clause 12.2.1.3 the AP maintains two active TEKs per SAID. The AP includes in its Key 
Reply messages both of these TEKs along with their remaining lifetimes. The AP encrypts downlink traffic with the 
older of its two TEKs and decrypts uplink traffic with either the older or newer TEK, depending upon which of the two 
keys the AT was using at the time. The AT encrypts uplink traffic with the newer of its two TEKs and decrypts 
downlink traffic with either the older or newer TEK, depending upon which of the two keys the AP was using at the 
time. See clause 6 for details on AT and AP key usage requirements. 
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Through operation of a TEK FSM, the AT attempts to keep its copies of an SAID's TEKs synchronized with those of its 
AP. A TEK FSM issues RlcTekReq messages to refresh copies of its SAID's keying material soon after the scheduled 
expiration time of the older of its two TEKs and before the expiration of its newer TEK. To accommodate for AT/AP 
clock skew and other system processing and transmission delays, the AT schedules its RlcTekReq messages a 
configurable number of seconds before the newer TEK's estimated expiration in the AP. With the receipt of the Key 
Reply message, the AT shall always update its records with the TEK Parameters from both TEKs contained in the Key 
Reply Message. Figure 52 illustrates the AT's scheduling of its key refreshes in conjunction with its management of an 
SAID's active TEKs. 



Table 38: TEK FSM State Transition Matrix 
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12.2.3.1 States 

Start: This is the initial state of the FSM. No resources are assigned to or used by the FSM in this state, i.e. all timers are 
off and no processing is scheduled. 

Initial Tek: This is the intermediate state to Op Wait state. The TEK FSM has sent its initial request for its SAID keying 
material and is waiting for a initial, first TEK allocation message from the AP.Operational Wait (Op Wait): The TEK 
FSM has sent its request (RlcTekReq message) for its SAID's keying material (TEK and CBC IV parameter), and is 
waiting for a reply from the AP. 

Operational Reauthorize Wait (Op Reauth Wait): The wait state the TEK FSM is placed in if it does not have valid 
keying material while the Authorization FSM is in the middle of a reauthorization cycle. 

Operational: The AT has valid keying material for the associated SAID. 

Rekey Wait: The TEK Refresh Timer has expired and the AT has requested a key update for this SAID. Note that the 
newer of its two TEKs has not expired and can still be used for both encrypting and decrypting data traffic. 

Rekey Reauthorize Wait (Rekey Reauth Wait): The wait state the TEK FSM is placed in if the TEK FSM has valid 
traffic keying material, has an outstanding request for the latest keying material, and the Authorization FSM initiates a 
reauthorization cycle. 



ETSI 



157 



ETSI TS 102 000 V1.3.1 (2002-12) 



12.2.3.2 Messages 

Key Request: An RlcTekReq message is sent from an AT to its AP requesting a TEK for the privacy of its authorized 
SAID. 

Key Reply: An RlcTekAllocation message is sent from an AP to an AT carrying only the new traffic keying material 
for the SAID. The message includes the SAID's TEKs, triple DES encrypted with the AK. The RlcTekAllocation 
message is authenticated with an HMAC. Additionally the "initializationStatus" bit is provided with this message. This 
status information is only used during the first TEK allocation procedure. It indicates that the other capability 
negotiations can start hereafter. 

Key Reject: An RlcTekReject message is sent from an AP to an AT indicating that the SAID is no longer valid and no 
key will be sent. The RlcTekReject message is authenticated with a HMAC. 

TEK Invalid: An RlcTeklnvalid message is sent from an AP to an AT if it determines that the AT encrypted uplink 
traffic with an invalid TEK, i.e. an SAID's TEK key sequence number, contained within the received MAC PDU 
Header, is out of the AP's range of known, valid sequence numbers for that SAID. 

12.2.3.3 Configuration parameters 

If Privacy is enabled, all Privacy configuration parameters shall be present and shall be supported by all ATs. 

Operational Wait Timeout: Timeout period between sending of two consecutive RlcTekReq messages from the Op Wait 
state. 

Rekey Wait Timeout: Timeout period between sending of two consecutive RlcTekReq messages from the Rekey Wait 
state. 

TEK Grace Time: Time interval before the estimated expiration of a TEK that the AT starts rekeying for a new TEK. 
TEK Grace Time shall be the same across all SAIDs. 

12.2.3.4 Events 

Stop: Sent by the Authorization FSM to an active (non-Start state) TEK FSM to terminate the TEK FSM and remove 
the corresponding SAID's keying material from the AT's key table. 

Authorized: Sent by the Authorization FSM to a non-active (Start state) TEK FSM to notify the TEK FSM of successful 
authorization. 

Authorization Pending (Auth Pend): Sent by the Authorization FSM to a TEK FSM to place the TEK FSM in a wait 
state while Authorization FSM completes reauthorization. 

Authorization Complete (Auth Comp): Sent by the Authorization FSM to a TEK FSM in the Operational Reauthorize 
Wait or Rekey Reauthorize Wait state to clear the wait state begun by the prior Authorization Pending event. 

TEK Invalid: This event may be triggered by either an AT's data packet decryption logic or by the receipt of an 
RlcTeklnvalid message from the AP. An AT's data packet decryption logic shall trigger a TEK Invalid event if it 
recognizes a loss of TEK key synchronization between itself and the encrypting AP, i.e. an SAID's TEK key sequence 
number, contained within the received downlink MAC PDU Header, is out of the AT's range of known sequence 
numbers for that SAID. An AP shall send an AT an RlcTeklnvalid message, triggering a TEK Invalid event within the 
AT, if the AP's decryption logic recognizes a loss of TEK key synchronization between itself and the AT. 

Timeout: A retry timer timeout. Generally, the particular request is retransmitted. 

TEK Refresh Timeout: The TEK refresh timer timed out. This timer event signals the TEK FSM to issue a new 
RlcTekReq message in order to refresh its keying material. The refresh timer is set to fire a configurable length of time 
(TEK Grace Time) before the expiration of the newer TEK the AT currently holds. This is configured via the AP to 
occur after the scheduled expiration of the older of the two TEKs. 
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12.2.3.5 Actions 

l-B received Stop event, transition from Op Wait to Start: 

• clear Key Request retry timer, 

• terminate the TEK FSM. 

1-C received Stop event, transition from Op Reauth Wait to Start: 

terminate the TEK FSM. 
1-D received Stop event, transition from Operational to Start: 

• clear TEK refresh timer, which is a timer set to go off "TEK Grace Time" seconds prior to the TEK's 
scheduled expiration time, 

terminate the TEK FSM, 

• remove the SAID keying material from key table. 

1-E received Stop event, transition from Rekey Wait to Start: 

• clear Key Request retry timer, 
terminate the TEK FSM, 

• remove the SAID keying material from key table. 

1- F received Stop event, transition from Rekey Reauth Wait to Start: 

terminate the TEK FSM, 

• remove the SAID keying material from key table. 

2- A received Authorized event, transition from Start: to Op Wait: 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Operational Wait Timeout. 

3- B received Auth Pend event, transition from Op Wait to Op Reauth Wait: 

• clear Key Request retry timer. 

3- E received Auth Pend event, transition from Rekey Wait to Rekey Reauth Wait: 

• clear Key Request retry timer. 

4- C received Auth Comp event, transition from Op Reauth Wait to Op Wait: 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Operational Wait Timeout. 

4- F received Auth Comp event, transition from Rekey Reauth Wait to Rekey Wait: 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Rekey Wait Timeout. 

5- D received TEK Invalid event, transition from Operational to Op Wait: 

• clear TEK refresh timer, 

• send RlcTekReq message to AP, 

• set Key Request retry timer to Operational Wait Timeout, 
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• remove the SAID keying material from key table. 

5-E received TEK Invalid event, transition from Rekey Wait to Op Wait: 

• clear Key Request retry timer, 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Operational Wait Timeout, 

• remove the SAID keying material from key table. 

5- F received TEK Invalid event, transition from Rekey Reauth Wait to Op Reauth Wait: 

• remove the SAID keying material from key table. 

6- B received Timeout event, transition from Op Wait to Op Wait: 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Operational Wait Timeout. 

6- E received Timeout event, transition from Rekey Wait to Rekey Wait: 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Rekey Wait Timeout. 

7- D received TEK Grace Timeout event, transition from Operational to Rekey Wait: 

• send RlcTekReq message to the AP, 

• set Key Request retry timer to Rekey Wait Timeout. 

8- B received RlcTekAllocation message, transition from Op Wait to Operational 

• clear Key Request retry timer, 

• process contents of RlcTekAllocation message and incorporate new keying material into key database, 

• set the TEK refresh timer to go off "TEK Grace Time" seconds prior to the key's scheduled expiration. 

8- E received RlcTekAllocation message, transition from Rekey Wait to Operational 

• clear Key Request retry timer, 

• process contents of RlcTekAllocation message and incorporate new keying material into key database, 

• set the TEK refresh timer to go off "TEK Grace Time" seconds prior to the key's scheduled expiration time. 

9- B received RlcTekReject message, transition from Op Wait to Start: 

• clear Key Request retry timer, 
terminate the TEK FSM. 

9-E received RlcTekReject message, transition from Rekey Wait to Start: 

• clear Key Request retry timer, 

• terminate the TEK FSM, 

• remove the SAID keying material from key table. 

8-G received RlcTekAllocation message, transition from Initial TEK to OP Wait. 
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12.3 TEK usage 
12.3.1 TEK usage for APs 

The AP's first receipt of an Authorization Request message from an unauthorized AT shall initiate the activation of a 
new AK, which the AP sends back to the requesting AT in an Authorization Reply message. This AK shall remain 
active until it expires according to its predefined lifetime, AK Lifetime, which is an AP system configuration parameter. 

The AP shall use the AT's AK for: 

• encrypting (triple-DES with EDE-mode) the TEKs in the RlcTekAllocation messages it sends to that AT, and 

• calculating the HMAC-Digests it writes into RlcTekAllocation messages sent to that AT. 

The AP shall reply to the AT's request of an AK. The AP shall be able to support up to two simultaneously active AKs 
for each AT. The AP shall have two active AKs during any AK transition period. The two active keys shall have 
overlapping lifetimes. 

An AK transition period begins when the AP receives an RlcAuthReq message from an AT and the AP has a single 
active AK for that AT. In response to this RlcAuthReq message, the AP activates a second AK, which it shall send back 
to the requesting AT in an RlcAuthReply message. The AP shall set the active lifetime of this second AK to be the 
remaining lifetime of the first AK, plus the predefined AK Lifetime. Thus, the second, "newer" key will remain active 
for one AK Lifetime beyond the expiration of the first, "older" key. The key transition period will end with the 
expiration of the older key. 

The Authorization Key lifetime that an AP reports in its RlcAuthReply message shall reflect, as accurately as an 
implementation permits, the remaining lifetimes of the AK at the time the message is sent. 

As long as the AP is in the midst of an AT's AK transition period, and thus is holding two active AKs for that AT, it 
shall respond to RlcAuthReq messages with the newer of the two active keys. Once the older key expires, an 
RlcAuthReq message shall trigger the activation of the newer AK and start a new key transition period. 

If an AT fails to reauthorize before the expiration of its most current AK, the AP shall hold no active AKs for the AT 
and shall consider the AT unauthorized. An AP shall remove from its keying tables all TEKs associated with an 
unauthorized AT. 

An AP shall use one of the AT's two active AKs to verify the HMAC -digest in RlcTekReq messages received from the 
AT. If an AP receives an RlcTekReq message while in an AK transition period, and the accompanying AK Key 
Sequence Number indicates the RlcTekReq message is authenticated with the newer of the two AKs, the AP identifies 
this as an implicit acknowledgment that the AT has obtained the newer of the AT's two active AKs. 

An AP shall use an active AK when calculating HMAC-Digests in Key Reply and RlcTekReject messages, and when 
encrypting the TEK in RlcTekAllocation messages. When sending Key Reply and RlcTekReject messages within a key 
transition period (i.e. when two active AKs are available), if the newer key has been implicitly acknowledged, the AP 
shall use the newer of the two active AKs. If the newer key has not been implicitly acknowledged, the AP shall use the 
older of the two active AKs. 

The AP shall maintain two valid TEKs per SAID. The two valid TEKs shall have overlapping lifetimes determined by 
the TEK Lifetime, which is a predefined AP system configuration parameter. The newer TEK shall have a key sequence 
number one greater than (modulo 4) that of the older TEK. Each TEK shall become active half way through the lifetime 
of its predecessor, and shall expire half way through the lifetime of its successor. Once a TEK's lifetime expires, the 
TEK shall become inactive and shall no longer be used. 

The Privacy Key Management protocol defined in the present document describes a mechanism for synchronizing this 
keying information between an AP and its ATs. It shall be the responsibility of the AT to update its keys in a timely 
fashion. The AP shall transition to a new downlink encryption key regardless of whether an AT has retrieved a copy of 
that TEK. 
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12.3.2 TEK usage for ATs 

All ATs shall be responsible for sustaining authorization with their AP(s) and maintaining an active AK. An AT shall 
be prepared to use its two most recently obtained AKs. All AKs shall have a limited lifetime and must be periodically 
refreshed. An AT refreshes its AK by re -issuing an RlcAuthReq message to its AP. The Authorization FSM 
(see clause 12.2.2) manages the scheduling of RlcAuthReq messages for refreshing AKs. 

An AT's Authorization FSM schedules at the beginning of reauthorization a configurable length of Authorization Grace 
Time (AGT) before the AT's latest AK is scheduled to expire. The AGT is configured to provide an AT with an 
authorization retry period that is sufficiently long to allow for system delays and provide adequate time for the AT to 
successfully complete an Authorization exchange before the expiration of its most current AK. 

Note that the AP does not require knowledge of the AGT. The AP, however, shall track the lifetimes of its AKs and 
shall deactivate a key once it has expired. 

An AT shall use the newer of its two most recent AKs when calculating the HMAC-Digests it attaches to RlcTekReq 
messages. It shall be able to use either of its two most recent AKs to authenticate Key Reply and RlcTekReject 
messages, and to decrypt an RlcTekAllocation message's encrypted TEK. The AT shall use the accompanying AK Key 
Sequence Number to determine which of the two AKs to use. 

1 2.3.3 Encryption and decryption with TEK 

Only the payload part (with 5 1 bytes) of every unicast MAC data PDU shall be encrypted. 

A block cipher is used, based on the single-DES (64 bit from the first part of the TEK field) with CBC mode. The CBC 
IV of 64 bit shall be calculated from the 24-bit frame counter for the frame that is used for the transmission and the 
64-bit IV parameter. The IV parameter shall be generated by the AP randomly and it shall be sent by the AP to the AT 
in RlcTekAllocation message. The CBC IV is a XOR of the IV parameter and the frame counter (with padding of 
40 zeros). 

msb Isb 



CBC IV (64 bits) 



IV parameter (random value, 64 bits) 



XOR 



padding (40 bits: '0000000..'.) frameCounter(24 bits) 

Figure 53: CBC IV generation 

If the use of triple-DES (128 bit TEK) was negotiated during initialization, then the encrypt-decrypt-encrypt (EDE) 
mode shall be applied. The CBC-mode and the IV generation shall be identical to the single-DES usage. 

The implementation of triple-DES for the encryption and decryption of MAC data PDUs is optional both for AP and 
AT. 
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1 3 Connection Control (CC) 

Connections can be created, changed or deleted, where this can be initiated by AP or AT. This shall be accomplished 
through a series of MAC management messages that are defined in the next clauses together with the procedures for 
Connection Set-up, Connection Change and Connection Release. 

The following rules shall be applied: 

• The AP has all necessary knowledge to determine what has to be done at any time as far as the connection 
establishment or change or deletion procedures are concerned. The AP shall either approve or disapprove all 
connection management proposals by the AT. 

• Either the AP or the AT can initiate a connection termination procedure only in response to the reception of a 
deletion primitive from the higher layers (except for re -initialization procedures). The connection deletion 
procedure priority is higher than all other connection control procedures. 

When setting a connection the QoS parameters for the MAC PDUs exchanged on the connection itself are implicitly 
defined. 

13.1 Common part layer primitives (informative only) 

The HA DLC layer supports 18 different service primitives at the DLC Service Access Point. These primitives can be 
divided up into four different groups according to the related procedure. The complete list is reported in hereafter: 

• Connection addition: 

DlcConnectionAdditionlnitReq 

DlcConnectionAdditionlnitlnd 

DlcConnectionAdditionReq 

DlcConnectionAdditionlnd 

DlcConnectionAdditionRsp 

DlcConnectionAdditionCnf 

• Connection change: 

DlcConnectionChangelnitReq 

DlcConnectionChangelnitlnd 

DlcConnectionChangeReq 

DlcConnectionChangelnd 

DlcConnectionChangeRsp 

DlcConnectionChangeCnf 

• Connection deletion: 

DlcConnectionDeletionReq 
DlcConnectionDeletionlnd 
DlcConnectionDeletionRsp 
DlcConnectionDeletionCnf 



ETSI 



163 



ETSI TS 102 000 V1.3.1 (2002-12) 



• Data: 

DlcDataReq 
DlcDatalnd 

When a request for establish/change/delete for a specific connection is received at one of the end points the "request" or 
the "init request" primitive is generated within the requesting entity. The term "ink" in the primitive name means that 
the requesting entity is the AT and a different kind of Connection Establishment/Change procedure is initiated. This 
request is transmitted by means of management messages to the peer RLC Layer, and, as a consequence, an "indication" 
or "init indication" primitive is generated. The answer of the non-initiating DLC entity is reported within the Response 
primitive. In this primitive is also contained (if possible) the reasons why the request is accepted or refused. Finally an 
RLC messages is transmitted to the originating side and as a consequence a "confirm" primitive is generated to the 
original requesting entity. 

In some cases, it is not necessary to send any information and the "confirm" primitive is issued directly by the RLC on 
the originating side. Such cases may occur, for example, when the RLC entity on the requesting side rejects the request. 
In figure 54 there is a description of the use of primitives. 
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Figure 54: Use of primitives 



13.1.1 Use of primitives 

In this clause an example of how the primitives and messages are generated and exchanged in case a connection has to 
be created is given. Two different cases have to be considered: 

• The initiating side is the AT: the initiating Convergence Layer entity sends a DlcConnectionAdditionlnitReq 
primitive to the relevant RLC Layer. The initiating side RLC Layer sends the appropriate 
RlcConnectionAdditionlnit message. The non-initiating RLC side generates an "init indication" primitive 
towards the relevant Convergence Layer and waits for a DlcConnectionAdditionReq primitive. If there is the 
possibility to establish the requested connection, then an RlcConnectionAdditionSetup message is sent. The 
initiating side responds to the relevant CL with an "indication" primitive. The reply coming from the upper 
layer is contained in the DlcConnectionAdditionRsp and as a consequence the RlcConnectionAdditionAck 
message shall be sent at RLC level. When it is received, a "confirmation" primitive is generated towards the 
CL of the initiating entity (AT) and this represents the end of the events sequence. At any point along the way, 
the request may be rejected. 

• The initiating side is the AP: the initiating Convergence Layer entity sends a DlcConnectionAdditionReq 
primitive to the relevant RLC Layer. This causes the sending of an RlcConnectionAdditionSetup message 
from the initiating side. The non-initiating side issues to the relevant CL an "indication" primitive. The reply 
coming from the upper layer is contained in the DlcConnectionAdditionRsp and as a consequence the 
RlcConnectionAdditionAck message shall be sent at RLC level. When it is received, a "confirmation" 
primitive is generated towards the CL of the initiating entity and this represents the end of the events sequence. 
At any point along the way, the request may be rejected. 
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This algorithm is valid also in case of a Connection Change procedure by using the correct messages/primitives. 

The DLC layer is never responsible of connection deletion; in case of link failure there will be no notification to the 
higher layers. The DLC is instead responsible of recovering from the failure unless a specific deletion issue is received 
from the upper layer. 

For Connection Deletion the events sequence is described in diagram 34. If this sequence starts when some of the 
former procedures for the same connection have not yet been completed, it will overrule the others causing an abortion 
of the former procedures and the deletion of the connection. 

DlcDataReq and DlcDatalnd are used during the usual transport of data when the connection the data is exchanged on 
has already been established. 

13.1.2 DIcConnectionAdditionlnitReq 

When a new connection is to be established, and the initiating entity is the AT then the DIcConnectionAdditionlnitReq 
primitive shall be issued from the Convergence Layer of the generating entity to the relevant RLC Layer. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionAdditionlnitReq 
( 

Scheduling service type, 
Convergence Layer ID, 
Convergence Layer parameters, 
Encryption indicator, 
ARQ on/off 

ARQ number of retransmissions 

Sequence number 

) 

The Convergence Layer (CL) parameter indicates the Convergence Layer that data received on this connection shall 
refer to. There shall be one specific value for each specific convergence Layer type plus a specific value indicating that 
no convergence Layer is used. 

This CID shall be returned to the requesting convergence Layer via the "confirmation" primitive. 

13.1.3 DIcConnectionAdditionReq 

When a new connection is to be established, and the initiating entity is the AP then the DIcConnectionAdditionReq 
primitive shall be issued from the Convergence Layer of the generating entity to the relevant RLC Layer. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionAdditionReq 
( 

Scheduling service type, 
Convergence Layer ID, 
Convergence Layer parameters, 
Encryption indicator, 
ARQ on/off 

ARQ number of retransmissions 

Sequence number 

) 
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13.1 .4 DIcConnectionAdditionlnitlnd 

The use of this primitive applies to the AT initiating Connection Establishment procedure. The RLC Layer of the AP 
generates this primitive when it receives an RlcConnectionAdditionlnit message from the initiating side at RLC level. 

The parameters contained in the primitive are listed hereafter: 

DlcConnect ionAddit ionlnd 
( 

Service type, 
Convergence Layer, 
Convergence Layer Parameters, 
Sequence number 
) 

13.1.5 DIcConnectionAdditionlnd 

The use of this primitive applies to the AP initiating Connection Establishment procedure. The RLC Layer of AT 
generates this primitive when it receives an RlcConnectionAdditionSetup message from the initiating side at RLC level. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionAdditionlnd 
( 

Service type, 

Connection ID, 

Convergence Layer, 

Convergence Layer Parameters, 

Sequence number 

) 

13.1.6 DIcConnectionAdditionRsp 

This primitive is generated by the Convergence Layer entity when it has received a DIcConnectionAdditionlnd 
primitive. This event causes the RLC Layer to send the RlcConnectionAdditionAck message. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionAdditionRsp 
( 

Response code, 
Sequence number, 
ARQ on/off 

ARQ number of retransmissions 
) 

The response code indicates success or the reason for rejecting the request. 

The sequence number is returned to the requesting entity to correlate this response with the original request. 

13.1.7 DIcConnectionAdditionCnf 

This primitive confirms that a connection has been successfully established. This primitive is generated after the receipt 
of the RlcConnectionAdditionAck message. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionAdditionCnf 
( 

Connection ID, 
Response code, 
Sequence number 
ARQ on/off 

ARQ number of retransmissions 
) 
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13.1.8 Changing an existing connection 

The following primitives are used: 

• DlcConnectionChangelnitReq 

• DlcConnectionChangelnitlnd 

• DlcConnectionChangeReq 

• DlcConnectionChangelnd 

• DlcConnectionChangeRsp 

• DlcConnectionChangeCnf 

The meaning of these primitives together with all-relevant parameters and consequent actions are exactly the same as 
creating primitives. 

13.1.9 DIcConnectionDeletionReq 

When a Connection Deletion is to be performed, the DIcConnectionDeletionReq primitive shall be issued. This 
primitive can be generated by convergence Layer of either an AP or an AT. 

As a consequence of receiving this primitive an RlcConnectionDeletionlnit message is sent to the non-initiating side 
and if it is received correctly the connection shall be terminated. Higher levels can initiate the deletion procedure at any 
moment. It will immediately cause the effect of tearing down the DLC connection, regardless of other procedures that 
were being performed upon the same connection. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionDeletionReq 
( 

Connection ID 
) 

The only parameter needed is the Connection ID that specifies which connection is to be terminated. 

13.1.10 DIcConnectionDeletionlnd 

This primitive is issued by the non-initiating side entity at the RLC level towards the CL. It requires the termination of a 
connection. 

This primitive is generated by the RLC Layer when it receives an RlcConnectionDeletionlnit message. The parameters 
contained in the primitive are listed hereafter: 

DIcConnectionDeletionlnd 
( 

Connection ID 
) 

13.1.11 DIcConnectionDeletionRsp 

When a CL entity receives an indication primitive it generates the DIcConnectionDeletionRsp primitive. The receipt of 
this primitive causes the RLC Layer to pass the RlcConnectionDeletionAck message. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionDeletionRsp 
( 

Connection ID, 
Response code, 
) 

The response code indicates if the deletion has been successful or the reason for the rejection. 
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13.1.12 DIcConnectionDeletionCnf 

The receipt of this primitive is the confirmation that a connection has been terminated. Connection ID contained in the 
primitive shall be no longer used for transmission of data. 

The parameters contained in the primitive are listed hereafter: 

DIcConnectionDeletionCnf 
( 

Connection ID, 
Response code, 
) 

13.1.13 DIcDataReq 

A convergence Layer generates this primitive whenever data is to be transferred to a peer entity or entities. The 
specified Connection ID shall be used at RLC level together with the relevant QoS parameters. QoS parameters have 
been already defined for the considered connection during the Connection Establishment procedure. 

The parameters contained in the primitive are listed hereafter: 

DIcDataReq 
( 

Connection ID, 

Length, 

Data, 

) 

DLC SDU is reported in the primitive as Data parameter. 

13.1.14 DIcDatalnd 

This primitive is generated whenever an RLC SDU is to be transferred to a peer convergence entity or entities. 
The parameters contained in the primitive are listed hereafter: 

DIcDatalnd 
( 

Connection ID, 

Length, 

Data, 

CS pass through 
) 

The Connection ID parameter specifies the connection used at RLC level to transport data. 



ETSI 



168 



ETSI TS 102 000 V1.3.1 (2002-12) 



13.2 MSC diagrams (informative only) 

Hereafter the events sequences for each procedure are depicted. Both primitives and RLC messages involved in the 
procedures are specified. 



MSC CC SP AT Init Connection Addition 



Sequence of events 
when the AT initiates a 
Connection Additon Procedure 



AP_CIEnfty 



DIcCo n nection Ad d hi on In it I nd 



AP_DlcEntity 



AT_DlcEntity 



AT_CIEntity 



DIcConnectionAdditionReq 



DIcConnectionAddifonCnf 



RIcC on nection Ad d hi on In it 



( /*Transactionld, Clid, 

ConnectionCIParameters.Scid, 
DirectionChoice.ArqUsag */ 

) 



RIcCo n nection Ad d it on Setup 



(/Transactions, AssignedCid, AssignedCaid, 
PmAssociation,Clid, ConnectionCIParameters, 
Scid,DirectionChoice, ArqUsage, 
Said, Contention Flag,ConfirmationCode 7 



RIcC on nection Ad d hi on Ack 



( /* Transactionld, AssignedCid, 
ConfirmationCode 7 



DIcCo nn ectio nAdd itio nl ni tR eq 



DIcC on nection Ad d iti on In d 



DIcC on nection Ad d hi on Rsp 



Diagram 30: MSC (4 entities) for AT initiated connection set up 



MSC CC SP AP Init Connection Addition 



Sequence of events 
when the AP initiates a 
Connection Additon Procedure 



AP_CIEn1ity 



AP_DlcEntity 



Dl cCon nection Addition Req 



RlcConnection Addition Setup 



AT_DlcEnthy 



AT_C Entity 



(/Transactionld, Ass ignedCid, AssignedCaid, 
PmAssociation.Clid, ConnectionCIParameters, 
Scid.DirectionChoice, ArqUsage, 
Said,ContentionFlag,Confirma1ionCode */ ) 



DIcC on nection Ad d iti on In d 



DlcCon nection Addition Rsp 



RIcC on nection Add iti on Ack 



DIcConnectionAddrSonCnf 



( /* Transactionld, AssignedCid, 
ConfirmationCode 7) 



Diagram 31 : MSC (4 entities) for AP initiated connection set up 
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MSC CC_SP_AT_Init_Connection_Change 



Sequence of events K 
when the AT initiates a 
Connection Change Procedure 



AP_ClEntity 



AP_DlcEntity 



DlcConnectionChangelnitlnd 



DlcConnectionChangeReq 



AT_DlcEntity AT_ClEntity 
DlcConnectionChangelnitReq 



RlcConnectionChangelnit 



( /* Transactionld, Cid, Scid, 
DirectionChoice,ArqUsage */ 



RlcConnectionChangeSetup 



(/* Transactionld, AssignedCid, AssignedCaid. 
PmAssociation.Scid, DirectionChoice, 
ArqUsage, ContentionFlag, 
ConfirmationCode */ 



RlcConnectionChangeAck 



DlcConnectionChangeCnf 



( /*TransactionId, AssignedCid, 
ConfirmationCode */) 



DlcConnectionChangelnd 



DlcConnectionChangeRsp 



Diagram 32: MSC (4 entities) for AT initiated connection change 



MSC CC_SP_AP_lnit_Connection_Change 



Sequence of events 
when the AP initiates a 
Connection Change Procedure 



AP_ClEntity 



AP_DlcEntity 



DlcConnectionChangeReq 



AT_DlcEntity 



AT_ClEntity 



RlcConnectionChangeSetup 



(/* Transactionld, AssignedCid, AssignedCaid. 
PmAssociation, Scid, DirectionChoice, 
ArqUsage, ContentionFlag, 
ConfirmationCode */ 



RlcConnectionChangeAck 



DlcConnectionChangeCnf 



( /*TransactionId, AssignedCid, 
ConfirmationCode */ 



DlcConnectionChangelnd 



DlcConnectionChangeRsp 



Diagram 33: MSC (4 entities) for AP initiated connection change 
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MSC CC SP Connection Deletion 



Sequence of events 

in a Connection Deletion Procedure 



Requesting 



CIEnfty 



Requesting 



DIcEntly 



Non Requesting 
Db Entity 



Non Requesting 
CIEntity 



DIcConnectionDeletionReq 



RlcCon n ectio nD eletion I n it 



(Transactiold, RequestedCid ) 



RlcCon nection DeletionAck 



DIcConnecfonDeletionCnf 



( Transactionld, RequestedCid, 
ConfirmationCode) 



DIcConnectionDeletionInd 



DIcConnectionDeletionRsp 



Diagram 34: MSC (4 entities) for AP/AT initiated connection release 



1 3.3 DLC service categories 

Four Service Categories are defined at the DLC level. In a descending priority order they are named: 

0) Periodic Real Time (PRT) 

1) Real Time (RT) 

2) Non Real Time (NRT) 

3) Best effort (BE) 

The Periodic Real Time service category has the highest priority; it is recommended to be used for the support of 
traditional CBR traffic such as El voice using AAL-1. It is recommended to use the same value for guaranteed and 
maximum bit rate. 

The Real Time service category has the next highest priority; it is recommended to use it for traffic with strict delay 
constraints. This is the only service category besides PRT for which it is possible to state the maximum value for 
Transfer Delay and Delay Variation introduced for a MAC PDU belonging to this class. It is described by the 
Maximum Bit Rate and the Guaranteed Bit Rate parameters (in addition to the Transfer Delay and Delay Variation 
parameters). 

The Non Real Time (NRT) service category has a lower priority with respect to the RT category. It is recommended to 
use the NRT for transporting traffic with a variable bit rate. No limitations on delay parameters are specified for this 
service category. It is described by both Maximum bit rate and Guaranteed bit rate since only a part of the requested 
bandwidth is always granted by the system. 

The Best Effort category is the lowest priority service class. It is recommended to use this category for transporting 
traffic with neither requirements on delay nor guaranteed bandwidth, allowing the system to perform a deep statistical 
multiplexing. No parameter is needed at the DLC level for this category. The Maximum Bit Rate parameter can be 
negotiated. 
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In order to achieve the service related to each Service Category listed above the following parameters shall be 
configured during the connection establishing phase. 

• Guaranteed bit rate: it is the guaranteed rate for the connection (it can be used or not by the connection, but, if 
requested, it is always available). 

• Maximum bit rate: it is the maximum rate allowed for the connection. 

• Maximum Burst Length: it is the maximum number of consecutive MAC PDUs that a connection is allowed to 
transmit. 

• Transfer Delay: it is the maximum delay that a PDU may experience in passing through the system. 

13.4 Connection control procedures 

In the following clauses the procedures for connection set-up, connection Change and connection deletion are 
described. 

Guard timers are needed on both sides to make the procedures able to recover from the loss of messages. Possible error 
scenarios are analyzed within the relevant clauses. 

Guard timers shall be achieved by AP and AT with simple calculations starting from the value set for the 
TimerGranuConnnection parameter. The AP communicates to the ATs the value for this parameter within the GBI 
message; see clause 8.8. The AP shall set this value within the range of 8-255 frames. The granularity for guard timers 
shall be selectable because the time needed to set, change, or delete a connection might be heavily dependent by the 
management system. 

Guard timers defined in the CC procedures shall be divided into two different categories: 

• Short timers: the duration of the Short timer shall be set to the value of TimerGranuConnnection parameter. 

• Medium timers: the duration of the Medium timer shall be set to 8 X (TimerGranuConnnection parameter). 
The AT shall use the latest received value of TimerGranuConnnection when setting the timers. 

Guard timers belonging to the Short category are: 

• T_ConnectionAdditionInit 

• T_ConnectionAdditionSetup 

• T_ConnectionChangeInit 

• T_ConnectionChangeSetup 

• T_ConnectionDeletionInit 

Guard timers belonging to the Medium category are: 

• T_ConnectionAdditionAck 

• T_ConnectionChangeAck 

• T_ConnectionDeletionAck 

The meaning of all these timers is described in the following clauses. 
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1 3.4. 1 Overview of protocol primitives 
13.4.1.1 HMSC of procedures 

An overview is provided with diagram 35. 



MSC CC ConnectionControlOverview 



KD 



CC_AT_lnit_Connection_Addition 



-o- 



CC_AP_Init_Connection_Addition 



CC_AT_Init_Connection_Change 





[ 


CC AP Init Connection Chanae 







CC_AT_Init_Connection_Deletion 



CC_AP_lnit_Connection_Deletion 



Diagram 35: HMSC for connection control messaging 
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13.4.1.2 Parameters 

All parameters to be communicated during the three procedures are relevant only to the data connections. Management 
connections are defined at the first initialization phase and have specific characteristics and parameters. The list of 
parameters is reported hereafter. 

• Connection Aggregate ID: Connection Aggregate ID (Caid) defines the way connections are considered at the 
AP side during their activity. The single connection is visible at the AP only at establishment, change and 
deletion operations. During the connection lifetime, they are handled only as part of the Connection Aggregate 
they belong to. The maximum number of possible CAs that the AP can establish with the same AT is 
negotiated in the initialization procedure. 

• Poll-me bit association: This parameter associates, or not, the connection aggregate ID specified in the 
previous field with the poll-me bit usage. The poll-me bit association shall have the same value for all the 
connections within the same connection aggregate. 

• Transaction ID: A Transaction ID is associated to each procedure by the initiating device (AP or AT). To help 
pre- vent ambiguity and provide simple checking, the Transaction ID number space is split between the AT and 
AP. In this case the AT shall select its Transaction IDs from the first half of the number space and the AP shall 
select its Transaction IDs from the second half of the number space. The transactions may consist of a 
request/response/confirmation or a setup/confirmation sequence. The response and confirmation messages 
shall return a confirmation code specifying whether the transaction had a positive ending or some exception 
condition was detected. 

• Service Category Identifier (Scld): Identifier of the DLC service category. 

• Contention Flag: For an uplink connection this parameter indicates if the AT is allowed to issue contention 
requests for bandwidth. 

• Convergence Layer Identifier (Clld): This parameter identifies the convergence layer the connection belongs 
to. 

• Convergence Layer Parameters (ConnectionClParameters): This parameter contains information used by the 
convergence layer. It's transported transparently by the DLC layer that passes this parameter to the higher 
layer. The format is a string octet of variable length. Each CL specification defines how this parameter is used. 

• Security Association Identifier (Said): This parameter shall be carried in Downlink direction only and 
indicates the association between the connection and the security association. 

• ARQ Usage: This parameter indicates the ARQ functionality for the connection. The possible options are the 
following (the value means that the function is disabled): 

No ARQ (0), 

Once ARQ (1), 

Twice ARQ (2). 

• Direction Choice: This parameter describes the characteristics of the data flow. It can assume 4 different forms 
depending on the direction of the transported data flow and if the data rate is symmetrical or not. Specifically: 

Uplink Direction 

Downlink Direction 

Bi-directional Symmetrical 

Bi-directional Asymmetrical 

In the first three cases the description contains only one entry, while in the last case two entries are needed. Each entry 
is composed by a list of parameters that characterize the connection: 

• Guaranteed bit rate: In the Real Time and Non Real Time service categories, this parameter means the amount 
of bandwidth that the system reserves to the connection. Its granularity is 1 kbit/s so that the maximum 
flexibility is achieved. 
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• Maximum bit rate: This parameter means the maximum load that the system can receive from the connection. 
It is mandatory for Real Time and Non Real Time service categories, while for the Best Effort traffic it can be 
an informative field. Its granularity is 1 kbit/s. 

• ConnectionMinPhyMode: For both Uplink and Downlink direction, this parameter indicates the most robust 
Phy Mode in which the AT has to consider the connection as active. If set to the lowest PHY mode, this 
parameter has no effect on connection handling. The minimum PHY mode shall be the same for all 
connections of a connection aggregate. 

13.4.2 Connection establishment procedure 

The DLC layer is connection-oriented and connection may be provisioned when one of the end points requires a new 
data flow to be transported or a subscriber needs to change its service parameters. 

A connection can be established within the first initialization phase, in a pre-provisioned way or dynamically created. 

Pre-provisioned connections are defined via provisioning by the network management system. The AP can be requested 
to establish a connection by specifying CID and the associated QoS parameters set. 

The CID is always assigned by the AP. The APC shall not assign the same CID to more than one connection per RF 
channel. In case of bi-directional connections, either symmetric or asymmetric, only one CID is assigned and it 
identifies the connection in both directions. 

Dynamic connections are created via signalling exchange at any time by the AP or by an already signed-on AT. In the 
dynamic connections establishment, both the AP and the AT can request to create an Uplink, Downlink or bi-directional 
connection. 

The procedure can be initiated by either the AP or the AT and can create only one Uplink, Downlink or bi-directional 
connection. Once it has been established, a connection can be modified with the Change procedure, by changing the 
parameter sets of the flow. Regardless the initiating entity the connection can be: 

• Downlink connection: the data flow that is transported by the considered connection flows in Downlink 
direction only. 

• Uplink connection: the data flow that is transported by the considered connection flows in Uplink direction 
only. 

• Bi-directional Symmetric connection: the connection transports data flows both in Uplink and in Downlink 
directions and the bit rate is symmetric (the same for the Uplink and the Downlink). 

• Bi-directional Asymmetric connection: the connection transports data flows both in Uplink and in Downlink 
directions and the bit rate is Asymmetric (different values for the Uplink or the Downlink). 

Once established, a bi-directional connection cannot be deleted in one way only. A bi-directional symmetric connection 
can be changed in a bi-directional asymmetric connection by means of a connection change procedure and vice-versa. 
Either the Uplink or Downlink set of parameter belonging to a specific asymmetric bi-directional connection can be 
changed independently. 

The algorithms for connection Establishment are (depending on the generating point): 

• AT initiated (only dynamic connections): Three-way handshaking. 

• AP initiated: Two-way handshaking. 

The three-way handshaking is needed in the former case because when the AT requires a new connection, it is not 
aware of the traffic load and can only request the AP to establish a connection with the proposed set of QoS parameters. 

If one of the requested QoS parameters exceeds some relevant limitations then the connection cannot be 
established/changed and a new set of values for the parameters shall be defined. 



ETSI 



175 



ETSI TS 102 000 V1.3.1 (2002-12) 



The AP may decide to group connections into Connection Aggregates according to its allocation mechanisms. The rules 
on grouping connections into CAs are: 

• Connection Aggregates cannot be defined among different ATs in Uplink direction. 

• Connections belonging to different QoS classes should not be grouped into the same connection aggregate. 

• When a connection is added to an aggregate the set of parameter of the aggregate shall be updated. 

• QoS info are required for grouping to CA (or for setup of new CA) and thus for choice of appropriate 
allocation mechanism. 

13.4.2.1 AT initiated connection establishment procedure 

The algorithm used for connection Establishment when initiated by the AT is based on the Three-way handshaking. The 
AT will request the AP for a connection with the RlcConnectionAdditionlnit message. If there are available resources 
and the AT has no basic limitations, the AP will send an RlcConnectionAdditionSetup message with all relevant 
information to the AT. The AT will confirm with an RlcConnectionAdditionAck message. The AP will not be allowed 
to schedule any data traffic before confirmation is received. 

In the RlcConnectionAdditionlnit message, the AT proposes values of the QoS parameters, but these values are decided 
by the AP and sent in the RlcConnectionAdditionSetup message. 

Guard timers are needed on both sides to make the procedure able to recover from the loss of messages. In particular 
three situations need to be handled by the use of timers, during the Establishment procedure initialized by the AT. 

The first case happens at the AT side in order to re-send the RlcConnectionAdditionlnit message. This timer is named 
T_ConnectionAdditionInit and it shall be configurable during first initialization procedure for the considered Terminal. 
When this timer expires and the RlcConnectionAdditionSetup message is not received the RlcConnectionAdditionlnit 
message is re-sent. The reason why the duration of this timer cannot be optimized in the general case is that the time the 
AP entity needs to send the Setup message after the RlcConnectionAdditionlnit message has been received is not only 
dependent from the DLC level but also on sector management actions. This timer is reset when the 
RlcConnectionAdditionSetup is received. 

The second timer needed is the T_ ConnectionAdditionSetup timer. It is defined at AP side and shall be configurable by 
the system management. This timer is reset when the RlcConnectionAdditionAck is received. If it expires without any 
reception of ack message, then the RlcConnectionAdditionSetup is re-sent. 

Finally a T_ConnectionAdditionAck timer is needed on both sides. This because the connection that is going to be 
established can be unidirectional or bi-directional and no data can be exchanged on the new connection ID until the ack 
message is received at AP side. So if no waiting time is foreseen there is the risk of losing data because the ID is not 
considered valid already. Each time the one at AT side expires without receiving an RlcConnectionAdditionSetup 
message an RlcConnectionAdditionAck is sent. At AP side after the AP has received the RlcConnectionAdditionAck 
message the T_ ConnectionAdditionSetup is reset and the T_ ConnectionAdditionAck is started. 

When T_ ConnectionAdditionAck timers at both side expires the new connection ID is considered valid and data can be 
exchanged on it. 

The recovering actions from message loss scenarios are described below: 

• Loss of RlcConnectionAdditionlnit: If the AT has not received an RlcConnectionAdditionSetup message from 
the AP when the T_ConnectionAdditionInit timer expires, the AT will issue a second 

RlcConnectionAdditionlnit message. In case the AT receives multiple RlcConnectionAdditionSetup messages 
then it shall discard the duplicate ones. 

• Loss of RlcConnectionAdditionSetup: If a duplicate RlcConnectionAdditionlnit message is received by the AP 
(entities are aware of duplicated messages from the Transaction ID field) before an 

RlcConnectionAdditionSetup message has been sent then the AP shall discard the message. If the AP receives 
an RlcConnectionAdditionlnit message when an RlcConnectionAdditionSetup message has already been sent 
then the RlcConnectionAdditionSetup message shall be re-sent. 
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• Loss of RlcConnectionAdditionAck: If the Ack message is lost then the AP shall re-send a further 

RlcConnectionAdditionSetup message until it receives the relevant ack. The AT is not aware of the loss of the 
ack message and the risk is that if the connection that is going to be established also encompasses the Uplink 
direction, the AT starts to transmit data using the new connection ID. So the AT shall wait for the expiring of 
T_ConnectionAdditionAck timer before transmitting in order to be sure that no further setup messages are 
received. 

Hereafter the MSC of the AT initiated Connection Addition procedure is reported. 



MSCCC AT Init Connection Addition 



AT initiated Connection Addition 
Procedure 



5 



AP 



AP decides about Said 



T_ConnectionAdditionSetup 



T ConnectionAdditionAck 



AT 



RIcConnectionAdditionlnit 



/* Transactionld, Clid, ConnectionCIParameters.Scid, 
DirectionChoice,ArqUsag 7) 



RlcConnectionAdditionSetup 



(/'Transactionld, AssignedCid, AssignedCaid,PmAssociatioi, 
Clid, ConnectionCIParameters,Scid,DirectionChoice, ArqUifage 
Said,ContentionFlag,ConfirmationCode 7 



RlcConnectionAdditionAck 



( /* Transactionld, AssignedCid, ConfirmationCode 7) 



AT can request 
a new Said 



T ConnectionAdditionlnit 



T ConnectionAdditionAck 




Diagram 36: MSC for AT initiated Connection Establishment 



13.4.2.2 AP initiated connection establishment procedure 

The algorithm used for connection Establishment when initialized by the AP is based on the Two-way handshaking 
mechanism. If AP needs to establish a new connection, the RlcConnectionAdditionSetup message is sent to the AT. 

In the RlcConnectionAdditionSetup message, the AP sends the values of the QoS parameters in accordance to the sector 
available resources. 

Since even in this procedure the direction of the connection is independent of the entity that initializes the procedure 
there is the need of a timer in order to ensure that both entities are not allowed to transmit data that could be lost using 
the new connection ID. 
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Hereafter the MSC of the AP connection Establishment procedure is reported. 



MSC CC AP Init Connection Addition 



AP initiated Connection Addition 
Procedure 



3 



AP decides about Said 



AP 



T_ConnectionAdditionSetup 



T_Connection Addition Ack 



AT 



RIcConnectionAdditionSetup 



(/Transactionld, AssignedCid, AssignedCaid.PmAssociation 
Clid, ConnectionCIParameters,Scid,DirectionChoice, Arqllpage, 
Said,ContentionFlag,ConfirmationCode 7 



RIcConnectionAdditionAck 



(/* Transactionld, AssignedCid, ConfirmationCode */) 



T_Connection Addition Ack 



Diagram 37: MSC for AP initiated Connection Establishment 



1 3.4.3 Change of established connection procedure 

The change of established connection procedure is needed when any connection parameters shall be modified. 

Both the AP and the AT can initiate a change of established connection procedure. There are several reasons why some 
QoS parameters shall be changed and sometimes they are not strictly relevant to the connection itself (load levelling or 
the initialization of a new subscriber, etc.). 

The Connection Change procedure is not used to change the CID of a connection. 

It shall be allowed to change the DirectionChoice parameter so that an asymmetric bi-directional connection is changed 
into a symmetric one and vice-versa. It shall not be allowed to use the Connection Change procedure to turn a 
uni-directional connection from uplink to downlink or vice-versa, neither to turn it into a bi-directional connection. 

The modification is achieved via signalling procedure described in diagram 38 when initiated by the AT and diagram 39 
when initiated by the AP. The procedure is the same as the connection Establishment. When initiated by the AT is 
based on the Three-way handshaking whereas when initiated by the AP is based on the Two-way handshaking. 

The formats of MAC management messages are the same as the messages exchanged in the connection Establishment 
procedure except for the RlcConnectionChangelnit that contains the Connection ID (CID) of the connection whose 
parameters are going to be exchanged. Hereafter the procedures are depicted. 

With connection change procedure it is not possible to change the convergence layer a connection belongs to. 
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MSC CC_AT_Init_Connection_Change 



AT initiated Connection Change 
Procedure 



AP 



AP decides about Said 



T_ConnectionChangeSetup 



T_ConnectionChangeAck 



AT 



RlcConnectionChangelnit 



( /* Transactionld, Cid, Scid, DirectionChoice.ArqUsage */) 



\ RlcConnectionChangeSetup 



(/* Transactionld, AssignedCid, AssignedCaid, PmAssociation, 
Scid, DirectionChoice, ArqUsage, ContentionFlag, 
ConfirmationCode */ 



RlcConnectionChangeAck 



( /*TransactionId, AssignedCid, ConfirmationCode */) 



AT can request 
a new Said 



T_ConnectionChangeInit 



T_ConnectionChangeAck 



Diagram 38: MSC for AT initiated connection change 



MSC CC_AP_Init_Connection_Change 



AP decides about Said 



T_ConnectionChangeSetup 



AP 



T_ConnectionChangeAck 



AP initiated Connection Change 
Procedure 



AT 



RlcConnectionChangeSetup 



(/* Transactionld, AssignedCid, AssignedCaid, PmAssociation, 
Scid, DirectionChoice, ArqUsage, ContentionFlag, 
ConfirmationCode */ ) 



RlcConnectionChangeAck 



( /* Transactionld, AssignedCid, ConfirmationCode */) 



T_ConnectionChangeAck 



Diagram 39: MSC for AP initiated connection change 
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13.4.4 Connection deletion procedure 

Every data connection can be released. When a connection is deleted, all resources associated to it are deleted. The 
connection ID value shall be available to be associated again to new connections and all the values regarding RF 
channel parameters shall be uploaded. 

Either the AP or the AT can initiate a connection termination procedure at any time only in response to the reception of 
a deletion primitive from the higher layers. This is the only occasion in which this procedure is initiated. The DLC layer 
shall always try to recover from failures without sending any warning to the upper layer until either the DLC connection 
is re-established or an incoming deletion primitive is received. 

The algorithm used for connection deletion is always a Two-way handshaking. 

Two different timers are needed in these procedures: 

• T_ConnectionDeletionInit: this is the timer that controls the re -transmission of the RlcConnectionDeletionlnit 
message. When this timer expires a further RlcConnectionDeletionlnit message is sent. This timer shall be 
implemented both in the AT and AP since both entities can initiate a Connection Deletion procedure. 

• T_ConnectionDeletionAck: this timer is needed in order to recover the loss of RlcConnectionDeletionAck 
message. In fact the non-initiating side will be sure that the ack message is received on the initiating side only 
if no further RlcConnectionDeletionlnit message is received. It can be concluded that both sides shall wait a 
waiting time corresponding to the expiring time of the T_ConnectionDeletionAck timer. 

The connection termination procedure is depicted in diagram 40 for AT and in diagram 41 for AP initiated connection 
termination respectively. The formats of the MAC management messages are specified in clause 13.6. 



MSC CC AT Init Connection Deletion 



AT initiated Connection t\ 
Deletion Procedure 



AP 



AT 



RlcConnectionDeletionlnit 



( TTransactiold, RequestedCid 7) 



T ConnectionDe letionlnit 



RlcConnectionDeletionAck 



(/* Transaction^, RequestedCid 7 ) 



1 Conn 5cti on Deletion Ack 



T ConnectionDelotionAck 



Diagram 40: MSC for AT initiated connection release 
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MSC CC AP Init Connection Deletion 



AP initiated Connection K 
Deletion Procedure 



AP 



AT 



RIcCo n nection Del et io nl ni t 



(/* Transaction, RequestedCid 7 



T ConneotionDeletionlnit 



RIcConnectionDeletionAck 



/* Transactions, RequestedCid*/) 



T ConnectionDeletionAck 



T ConnectionDeletionAck 



Diagram 41 : MSC for AP initiated connection release 



13.5 Multicast connections 

The same downstream (and only downstream) flow of information may have to be delivered to a group of different 
users (terminals), in this case a multicast connection can be established. This allows the AP to transmit information only 
once over the air interface. Several multicast groups with different sets of connections can exist in parallel. There is not 
a special procedure for setting up of a multicast connection. The AP establishes a Downlink unicast connection with 
each AT included in the multicast group assigning to the each connection the same CID. 

The AT is not aware of the multicast nature of the connection or of the other ATs included in the multicast group. 

Since the AP is the only part aware of the multicast groups, the maximum flexibility is achieved. 

All multicast groups can be dynamically updated, i.e. connections can be allocated to a group or withdrawn from a 
group or switched between two groups at any time with a normal unicast connection deletion and connection 
Establishment procedure. 
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13.6 Connection management message description 

Hereafter the ASN.l description of all messages exchanged in connection management procedures is reported: 
Table 39: ASN.1 Connection management messages description 

RlcConnectionAdditionlnit ::= SEQUENCE { 

transactionld Transactionld, — 17 bit 



clid 


Clid, 


— 3 bit 


connectionClParameter s ConnectionClParameter s , — variable 


scid 


Scid, 


— 2 bit 


directionChoice 


DirectionChoice, 


— variable 


arqUsage 


ArqUsage 


— 2 bit 


onnectionAdditionSetup ::= SEQUENCE { 




transactionld 


Transactionld, 


— 17 bit 


assignedCid 


AssignedCid, 


— 16 bit 


assignedCaid 


AssignedCaid, 


— 16 bit 


pmAssociation 


PmAssociation, 


— 1 bit 


clid 


Clid, 


— 3 bit 


connectionClParameter s ConnectionClParameter s , -- variable 


scid 


Scid, 


— 4 bit 


directionChoice 


DirectionChoice, 


— variable 


arqUsage 


ArqUsage, 


— 2 bit 


said 


Said, 


— 16 bit 


contentionFlag 


ContentionFlag, 


— 1 bit 


conf irmationCode 


Conf irmationCode 


— 1 bit 



} 



RlcConnectionAdditionAck ::= SEQUENCE { 
transactionld Transactionld, 
assignedCid AssignedCid, 
conf irmationCode Conf irmationCode 

} 



17 bit 
16 bit 
1 bit 



RlcConnect ionChangelnit 
transactionld 
cid 
scid 

directionChoice 
arqUsage 



SEQUENCE { 
Transactionld, 
Cid, 
Scid, 

DirectionChoice, 
ArqUsage 



17 bit 
16 bit 
2 bit 
variable 
2 bit 



RlcConnectionChangeSetup ::= SEQUENCE { 



transactionld 

assignedCid 

assignedCaid 

pmAssociation 

scid 

directionChoice 
arqUsage 
contentionFlag 
conf irmationCode 



Transactionld, 

AssignedCid, 

AssignedCaid, 

PmAssociation, 

Scid, 

DirectionChoice, 
ArqUsage, 
ContentionFlag, 
Conf irmationCode 



17 bit 
16 bit 
16 bit 

1 bit 

2 bit 
variable 
2 bit 

1 bit 
1 bit 



RlcConnect ionChangeAck 
transactionld 
assignedCid 
conf irmationCode 



: : = SEQUENCE { 
Transactionld, 
AssignedCid, 
Conf irmationCode 



— 17 bit 

— 16 bit 

— 1 bit 



RlcConnectionDeletionlnit : := SEQUENCE { 

transactionld Transactionld, — 17 bit 

requestedCid RequestedCid — 16 bit 

} 

RlcConnectionDeletionAck ::= SEQUENCE { 
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transactionld 
requestedCid 



} 



Transactionld, 
RequestedCid 



17 bit 
16 bit 



Conf irmationCode : 

connAccepted (0), 

connReject (1) 

} 

RequestedCid : 

AssignedCid : 

AssignedCaid : 

Transactionld : 

Clid : 



ENUMERATED { 



:= DataCid 
:= DataCid 

:= Caid 

:= INTEGER (0 . . 131071) 
:= INTEGER { 



cellBased ( 1 ) , 
packetBased (2) } (0 . . 7) 



— 1 bit, request status 



— 16 bit, temp for AT initiated req 

— 16 bit, temp for AT initiated req 

— 16 bit, temp for AT initiated req 

— 17 bit, uniquely assigned by sender 

— 3 bit 



ConnectionClParameter s : 
CBCS 



OCTET STRING (SIZE (0.. 63) 



— variable, contains VPI for 



Scid 

periodicRealTime 
realTime 
nonRealTime 
bestEf f ort 

} 

PmAssociation ::= 
pmAssociated (0), 
pmNonAssociated (1) 



■ ENUMERATED { 

(0) , 

(1) , 

(2) , 
(3) 



ENUMERATED { 



2 bit 



Said 



INTEGER (0 . . 65535) 



16 bit 



ArqUsage ::= ENUMERATED { 

noARQ ( ) , 

onceARQ (1) , 

twiceARQ (2) 

} 



ContentionFlag ::= 
con tentionReqsNot All owed 
con tentionReqs All owed 

} 

DirectionChoice ::= 
uplinkDirection 
downlinkDirect ion 
bidirectional Symmetrical 
bidirect ionalAsymmet rical 

} 

DirectionDescr ::= 
guar ant eedBit Rate 
maximumBitRate 
maximumBurstSize 
connect ionMinPhyMode 
transferDelay 



ENUMERATED { 
(0) , 
(1) 



1 bit 



CHOICE { 

DirectionDescr, 
DirectionDescr, 
DirectionDescr, 
Bidirect ionalAsymmet rical 



SEQUENCE { 

Guar ant eedBitRate, 

MaximumBitRate, 

MaximumBurstSize, 

UplinkPhyMode, — for all DL DirectionDescr 
TransferDelay 



Bidirect ionalAsymmet rical 
uplinkDirection 
downlinkDirect ion 

} 



SEQUENCE { 

DirectionDescr, 
DirectionDescr 



BitRate 



INTEGER ( 1 . . 130000) 



17 bit, granu=lkbit / s , max=130Mbit / s 
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Guar ant eedBitRate 


: : = BitRate 






MaximumBitRate 


: : = BitRate 






Trans ferDe lay 


: := INTEGER (0 


5 . . 63) 


-- 6 bit, granu=lms , max=63ms , 








-- means Transf erDelay=inf inity 


MaximumBurst Size 


: := INTEGER (0 


.255) 


— 8 bit, granu=lPduPayload=51byte 








means MaxBurstSize=inf inity 








applies only for data conns 
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Annex A (normative): 
Parameters and constants 

A. 1 List of optional/mandatory features 



Table A.1 : List of optional/mandatory features 



Feature 


AP 

status 


AT 

status 


Signalling 


UL preamble length 


S 


M 


initialization 


Frame offset 


S 


M 


GBI 


TDMA in DL 





M 

(only for H-FDD ATs) 


GBI 


One or several midambles per UL burst 


s 


M 


GBI 


One or several MAC PDUs per UL FEC block 


s 


M 


GBI 


64-QAM for DL 





O 


initialization 


16-QAM for UL 





O 


initialization 


Turbo code encoder 








initialization 


H-FDD capability 


M 





initialization 


Duplex mode 


s 





GBI 


Encryption mode 


s 


M 


GBI 


Contention resolution parameters 


s 


M 


GBI 


Contention resolution feature 








UL map, initialization 


PHY mode thresholds 


s 


M 


GBI 


PHY mode power steps 


s 


M 


GBI 


APC-ID 


s 


n/a 


control zone 


APC-ID check during initialization 


n/a 


O 


control zone 


Measurement report criteria 


S 


M 


GBI and individual message 


Legend: M = mandatory to handle the feature or all possible parameter value, 



O = optional, 

S = selected at AP (means that at least one of the possible options shall be implemented) 



NOTE: The signalling column only gives information where a feature or parameter is exchanged. 
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A.2 Detailed specification of PHY parameters in protocol 
primitives 



Table A.2: Detailed specification of PHY parameters carried by protocol primitives 



Parameter 


Description 


Messages containing the 
parameter 


Range 


Granularity 


Bit 


TimingAdjustRanging 


Adjustment of timing 
during initial ranging 


RIcRangingRsp 


[0, 80] 
MS 


0,25 
symbol 


13 


TimingAdjustFine 


Incremental timing 
correction 


RIcUplinkTimingCorrection 


[-2, +2] 

L ' J 

symbols 


0,25 
symbol 


5 


UplinkPowerlnc 


Incremental step for UL 
transmit power (full range 
only for ranging, otherwise 
[-4,+4]dB 


RIcRangingRsp, 
RlcUplinkPowerCorrection 


[-20, +41 
dB 


0,5 
dB 


6 


UplinkPowerlncRangingSt 
art 


Incremental increase of UL 
transmit power for ranging 


RIcGeneralBroadcastlnformation 


[+1 , +8] 
dB 


1 

dB 


3 


UplinkPowerModChange 


Incremental change step 
for UL power in case of 
PHY mode change, per 
PHY mode, per UL, per 
upgrade/downgrade. The 
high range is reserved for 
future PHY mode sets 


RIcGeneralBroadcastlnformation 


[-8, +8] 
dB 


0,5 
dB 


6 


UplinkPowerMax 


Max transmit power of AT 


RIcAtPhyCapabilitieslnfo 


[10, 20] 
dBm 


1 

dB 


4 


RxPowerMeasured 


Absolute measured 
received power in AT 


RIcDownlinkPhyModeChangeReq, 
RIcMeasurementReportData 


[-88, -28] 
dBm 


0,25 
dB 


8 


TxPowerMeasured 


Absolute current transmit 
power in AT 


RIcDownlinkPhyModeChangeReq, 
RIcMeasurementReportData 


[-26, 20] 
dBm 


1 

dB 


6 


TxPowerMargin 


Current transmit power 
margin in AT 


RIcDownlinkPhyModeChangeReq, 
RIcMeasurementReportData 


[0,12] 
dB 


0,25 
dB 


6 


CnrMeasured 


Absolute C/N measured in 
DL 


RIcDownlinkPhyModeChangeReq, 
RIcMeasurementReportData 


[4, 40] 
db 


0,25 
dB 


8 


CnrThreshold 


Absolute C/N threshold at 
AT to request DL PHY 
mode change, per PHY 
mode, per DL, per 
upgrade/downgrade 


RIcGeneralBroadcastlnformation 


[4, 40] 
db 


0,25 dB 


8 


PeriodReport 


Period for measurement 
reports 


RIcGeneralBroadcastlnformation, 
RIcMeasurementReportCriterium 


[50, 200] 
ms 


50 
ms 


3 


PeriodRangingReq 


Minimum period between 
subsequent ranging 
request messages 


RIcGeneralBroadcastlnformation 


[0,15] 
frame 


1 

frame 


4 


FrameOffset 


Frame offset 


RIcGeneralBroadcastlnformation 


[0,4, 1] 
ms 


0,05 ms 


5 


CrMaxNumberRetries 


CR max no of retries for 
bandwidth contention 


RIcGeneralBroadcastlnformation 


[1, 16] 
retries 


1 retry 


4 


CrStartingWindowSize 


CR starting window size 
for bandwidth contention 


RIcGeneralBroadcastlnformation 






3 


CrMaxBackoffWindow 


CR max backoff window 
for bandwidth contention 


RIcGeneralBroadcastlnformation 






6 
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A. 3 Timers 



Table A.3: Detailed specification of AP timers 



Name 


Duration 


Standard Ref. OR 
Operator- Defined 


AP Initialization Timers 


TRangingAck 






T_PhyCapabilitiesReq 






T_PhyCapabilitiesCnf 






T_OtherCapabilitiesReq 






T_OtherCapabilitiesCnf 






AP Connection Control Timers 


T_ConnectionAdditionSetup 






TConnectionAdditionAck 






T ConnectionChangeSetup 






T ConnectionChangeAck 






T ConnectionDeletionlnit 






T ConnectionDeletionAck 






AP Radio Resource Control Timers 


T DownlinkPhyModeChange 






T DownlinkPhyModeChangeAck 






T_UplinkCorrection 






T_Handover_Cmd 







Table A.4: Detailed specification of AT timers 



Name 


Duration 


Standard Ref. OR 
Operator- Defined 


AT Initialization Timers 


TRangingAck 






T_PhyCapabilitieslnfo 






T_PhyCapabilitiesCnf 






T_OtherCapabilitieslnfo 






T_OtherCapabilitiesCnf 






AT Connection Control Timers 


T ConnectionAdditionlnit 






T ConnectionAdditionAck 






T_ConnectionChangelnit 






TConnectionChangeAck 






T ConnectionDeletionlnit 






T_ConnectionDeletionAck 






AT Radio Resource Control Timers 


T_MeasurementReportData 






T_DownlinkPhyModeChangeAck 






T HandoverAck 
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Annex B (normative): 
Formats of protocol primitives 

The electronic attachment containing the ASN.l message description is the normative specification, just in case of 
discrepancies to this printed complete description and all printed extracts in clauses 1 to 13 (for the purpose of better 
readability). 

The statements about granularity and range of variables in the form of ASN.l comments are to be considered as 
normative specifications. 

PER encoding with byte alignment shall be applied to each message. 

Table B.1 : Complete ASN.1 description of protocol primitives 



************************************************************* 



Abbreviations: 


inc 




increment 




granu 




granularity 




ann 




announcement 




tx/ rx 




transmit/ receive 




cnr 




carrier-to- (noise&interf erence) ratio 




cr 




contention resolution 




at 




AT 




conn 




connection 




agg 




aggregate 




OD 




origination -> destination 




DO 




destination -> origination 




AK 




Authorization Key 




KEK 




Key Encryption Key 




MAK 




Message Authentication Key 




SA 




Security Association 




SAID 




Security Association Identifier 




TEK 




Traffic Encryption Key 



************************************************************* 



HAprotocolPrimit ives 
DEFINITIONS 

AUTOMATIC TAGS : := 

BEGIN 

EXPORTS RlcConnectionAdditionlnit, RlcConnectionAdditionSetup, 

RlcConnect ionAddit ionAck, RlcConnectionChangelnit , 

RlcConnect ionChangeSetup, RlcConnectionChangeAck, 

RlcConnect ionDelet ion Init , RlcConnectionDe let ionAck; 

************************************************************* 

— Lists of Messages 

************************************************************* 



MacManagementMessage ::= CHOICE { 

rlcGeneralBroadcastlnf ormation RlcGeneralBroadcastlnf ormation, — DL Br 

rlcFrequencyList RlcFrequencyList , — DL Br 

rlcMultipleTidBroadcastBasic RlcMultipleTidBroadcastBasic, — DL Br 



rlcBandwidthReq 

rlcQueueStatusReq 

rlcQueueStatusRsp 



RlcBandwidthReq, 

RlcQueueStatusReq, 

RlcQueueStatusRsp, 



UL Ba 
DL Ba 
UL Ba 



rlcRanginglnvitation 

rlcRangingReq 

rlcRangingCont inue 

rlcRangingSuccess 

rlcRangingAck 

rlcPhyCapabilitiesReq 



RlcRanginglnvitation, 
RlcRangingReq, 
RlcRangingCont inue, 
RlcRangingSuccess , 
RlcRangingAck, 
RlcPhyCapabilitiesReq, 



DL Ba 
UL Ba 
DL Ba 
DL Ba 
UL Ba 
DL Ba 
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rlcPhyCapabilities Inf o 
rlcPhyCapabilitiesCnf 
rlcOtherCapabilitiesReq 
rlcOtherCapabilitiesInf o 
rlcOtherCapabilitiesCnf 



RlcPhyCapabilities Inf o, 
RlcPhyCapabilitiesCnf, 
RlcOtherCapabilitiesReq, 
RlcOtherCapabilities Inf o, 
RlcOtherCapabilitiesCnf, 



UL Ba 
DL Ba 
DL Ba 
UL Ba 
DL Ba 



rlcInitializationCmd 
rlcMeasurement Report Data 
rlcDownlinkPhyModeChange 
rlcDownlinkPhyModeChangeAck 
rlcUplinkCorrect ion 
rlcMeasurement Reporter it erium 
rlcHandoverCmd 
rlcHandoverAck 



RlcInitializationCmd, — DL Ba 

RlcMeasurementReportData, -- UL Ba 

RlcDownlinkPhyModeChange, — DL Ba 

RlcDownlinkPhyModeChangeAck, — UL Ba 

RlcUplinkCorrection, — DL Ba 

RlcMeasurementReportCriterium, — DL Ba 

RlcHandoverCmd, — DL Ba 

RlcHandoverAck, UL Ba 



rlcAuthManuf acturerlnf o 

rlcAuthReq 

rlcAuthReply 

rlcAuthRe ject 

rlcAuth Invalid 

rlcTekReq 

rlcTek2Req 

rlcTekAl location 

rlcTekRe ject 

rlcTeklnvalid 



RlcAuthManuf acturerlnf o, 

RlcAuthReq, 

RlcAuthReply, 

RlcAuthRe ject, 

RlcAuth Invalid, 

RlcTekReq, 

RlcTek2Req, 

RlcTekAl location, 

RlcTekRe ject, 

RlcTeklnvalid, 



UL Pr 
UL Pr 
DL Pr 
DL Pr 
DL Pr 
UL Pr 
UL Pr 
DL Pr 
DL Pr 
DL Pr 



rlcConnect 
rlcConnect 
rlcConnect 
rlcConnect 
rlcConnect 
rlcConnect 
rlcConnect 
rlcConnect 



ionAdditionlnit 

ionAddit ionSetup 

ionAdditionAck 

ionChangelnit 

ionChangeSetup 

ionChangeAck 

ionDeletionlnit 

ionDeletionAck 



RlcConnect 
RlcConnect 
RlcConnect 
RlcConnect 
RlcConnect 
RlcConnect 
RlcConnect 
RlcConnect 



ionAdditionlnit , 
ionAddit ionSetup, 
ionAdditionAck, 
ionChangelnit , 
ionChangeSetup, 
ionChangeAck, 
ionDeletionlnit , 
ionDeletionAck, 



UL Ba 
DL Ba 
UL Ba 
UL Ba 
DL Ba 
UL Ba 

Req->NonReq Ba 
NonReq->Req Ba 



packedMessageDownlinkBasic 
packedMessageUplinkBasic 



PackedMessageDownlinkBasic, 
PackedMessageUplinkBasic 



DL Ba 
UL Ba 



Mess age sForPackingDownlinkBasic 
rlcQueueStatusReq 
rlcRangingCont inue 
rlcRangingSuccess 
rlcPhyCapabilitiesReq 
rlcPhyCapabilitiesCnf 
rlcOtherCapabilitiesReq 
rlcOtherCapabilitiesCnf 
rlcInitializationCmd 
rlcDownlinkPhyModeChange 
rlcUplinkCorrect ion 
rlcMeasurement Reporter it erium 
rlcConnect ionAddit ionSetup 
rlcConnect ionChangeSetup 
rlcConnect ionDeletionlnit 
rlcConnect ionDeletionAck 



Mess age sForPackingUplinkBasic 
rlcMeasurement Report Data 
rlcDownlinkPhyModeChangeAck 
rlcConnect ionAddit ion Init 
rlcConnect ionAddit ionAck 
rlcConnect ionChangelnit 
rlcConnect ionChangeAck 
rlcConnect ionDeletionlnit 
rlcConnect ionDeletionAck 
excluded for PackingUplink : rang 

init 



: := CHOICE { 
RlcQueueStatusReq, 
RlcRangingCont inue, 
RlcRangingSuccess , 
RlcPhyCapabilitiesReq, 
RlcPhyCapabilitiesCnf, 
RlcOtherCapabilitiesReq, 
RlcOtherCapabilitiesCnf, 
RlcInitializationCmd, 
RlcDownlinkPhyModeChange, 
RlcUplinkCorrection, 
RlcMeasurementReportCriterium, 
RlcConnect ionAddit ionSetup, 
RlcConnect ionChangeSetup, 
RlcConnect ionDeletionlnit , 
RlcConnect ionDeletionAck 



DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 
DL Ba 

Req->NonReq Ba 
NonReq->Req Ba 



:= CHOICE { 

RlcMeasurementReportData, 

RlcDownlinkPhyModeChangeAck, 

RlcConnect ionAddit ion Init , 

RlcConnect ionAdditionAck, 

RlcConnect ionChangelnit , 

RlcConnect ionChangeAck, 

RlcConnect ionDeletionlnit , 

RlcConnect ionDeletionAck 
ing bursts, short PDUs, 
ialization (due to PTC) , handoverAck 



UL Ba 
UL Ba 
UL Ba 
UL Ba 
UL Ba 
UL Ba 

Req->NonReq Ba 
NonReq->Req Ba 
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PackedMessageDownlinkBasic 
PackedMessageUplinkBasic 



:= SEQUENCE (SIZE(1..50) 
:= SEQUENCE (SIZE(1..50) 



OF MessagesForPackingDownlinkBasic 
OF MessagesForPackingUplinkBasic 



************************************************************* 

— Messages for Broadcast and MAC (Clause 1 to 8) 

************************************************************* 



RlcGeneralBroadcastlnf ormation : : 
duplexMode 
f rameOf f set 
tdmaZoneDownlink 
encrypt ionMode 
uplinkPower IncRangingStart 
uplinkPowerMaxRangingStart 
downlinkPowerControl 
periodMeasurementReportGBI 
periodRanginglnvitat ion 
timerGranuConnection 
timerGranuSecurity 
uplinkNumberPduPerFecBlock 
uplinkNumberMidamblePerBurst 
crMaxNumberRetries 
crStartingWindowSize 
crMaxBackoff Window 
f ixedVariableChannellnd 
phyMode Set Descriptor Cur rent 
phyModeSetDescriptorFuture 



SEQUENCE { 
DuplexMode, 
FrameOf f set, 
TdmaZoneDownlink, 
Encrypt ionMode, 
UplinkPower IncRangingStart , 
UplinkPowerMax, 
DownlinkPowerControl, 
PeriodMeasurementReportGBI , 
PeriodRanginglnvitat ion, 
TimerGranuConnection, 
TimerGranuSecurity, 
UplinkNumberPduPerFecBlock, 
UplinkNumberMidamblePerBurst , 
CrMaxNumberRetries , 
CrStartingWindowSize, 
CrMaxBackoff Window, 
F ixedVariableChannellnd, 
PhyModeSet Descriptor, 
PhyModeSetDescriptor OPTIONAL 



broadcast 
1 bit 
bit 
bit 
bit 
bit, 
bit , 
bit 
bit , 
bit, 
bit 
bit 
bit 
bit 
bit 
3 bit 
6 bit 
1 bit 
variable 
variable 



} 

DuplexMode 
fdd 
tdd 

} 

TdmaZoneDownlink 
present 
notPresent 

} 



: = ENUMERATED { 
(0) , 

(1) 



: = ENUMERATED { 
(0) , 

(1) 



DownlinkPowerControl ::= ENUMERATED { 
downlinkPowerControlNo (0) , 
downlinkPowerControlYes (1) 

} 



Encrypt ionMode 

encrypt ionOn 
encrypt ionOf f 

} 

FrameOf f set 



:= ENUMERATED { 

(0) , 

(1) 



common 
common 



RRC 



ignore PhyThresholdsList ( ) 



INTEGER (0 . .20) 



5 bit, granu=0,05 ms , range= [ , 1 ] 



PeriodRanginglnvitat ion 



TimerGranuConnection 
TimerGranuSecurity 



INTEGER (0 .. 255) — 8 bit, granu=1000 frame 
— means no invitations 



INTEGER ( 8 . .255) 
INTEGER (1 . . 63) 



8 bit, granu=l frame 
6 bit, granu=128 frame 



UplinkNumberPduPerFecBlock 
onePduPerFecBlock 
severalPerFecBlock 

} 



(0) , 
(1) 



UplinkNumberMidamblePerBurst : : 
oneMidamblePerBurst (0) 
severalMidamblePerBur st (1) 

} 



ENUMERATED { 



ENUMERATED { 
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CrMaxNumberRet ries 
CrStartingWindowSize 
CrMaxBackoff Window 



FixedVariableChannellnd 
fixedChannel (0), 
variableChannel (1) 

} 



INTEGER (0 . . 15) 
INTEGER (0 . . 7) 
INTEGER (0 . . 63) 



— 4 bit 
3 bit 

— 6 bit 



ENUMERATED { 

— shall be used 

— not allowed 



PhyModeSetDescriptor ::= SEQUENCE { 

psdi Psdi, — 4 bit 

downlinkPhyThresholdsList PhyThresholdsList , — variable 

uplinkPowerModChangeListNonTc UplinkPowerModChangeList , -- variable 

uplinkPowerModChangeListTc UplinkPowerModChangeList -- variable 

} 



Psdi 



INTEGER {phyModeSetl (1), phyModeSet2 (2)} (0..15) — 4 bit 



PhyThresholdsList ::= SEQUENCE (SIZE (2.. 7)) OF PhyThresholdPair 

— allows 2. .7 PHY modes per set, 2*8 bit per pair, see RRC 

— 1st pair for DL ATPC, to be ignored if no DL ATPC 

2nd pair for model /mode2 , 3rd pair for mode2/mode3, etc. 

UplinkPowerModChangeList ::= SEQUENCE ( SIZE ( 1 . . 6 ) ) OF UplinkPowerModChangePair 

— allows 2. .7 PHY modes per set, 6 bit per entry, see common 

— TX power steps for UL PHY change 

— 1st gap pair for model/mode2, 

— 2nd gap pair for mode2/mode3, etc. 



PhyThresholdPair 
upThreshold 
downThreshold 

} 



: := SEQUENCE { 
CnrThreshold, 
CnrThreshold 



channel quality increase 
— channel quality decrease 



UplinkPowerModChangePair ::= SEQUENCE { 

upPowerModChange UplinkPowerModChange, 
downPowerModChange UplinkPowerModChange 

} 



channel quality increase 
channel quality decrease 



RlcFrequencyList ::= SEQUENCE ( SI ZE ( 1 . . 32 ) ) OF PairOf CarrierFrequencies 



PairOfCarrierFrequencies ::= SEQUENCE { 

uplinkCarrierFrequency Carrie rFrequency, 

downlinkCarrierFrequency CarrierFrequency 

} 



CarrierFrequency 



INTEGER ( . . 130000) 



— equal to uplinkFrequency for TDD 
17 bit, granu=0,5 MHz, range=[0,65] GHz 



RlcMultipleTidBroadcastBasic ::= SEQUENCE ( SI ZE ( 1 . . 50 ) ) OF PairTidMessageBasic 

PairTidMessageBasic ::= SEQUENCE { 

tid Tid, 

mess ages For TidPackingBasic MessagesForTidPackingBasic 

} 

MessagesForTidPackingBasic ::= CHOICE { 



rlcQueueStatusReq 


RlcQueueStatusReq, 


— DL 


Ba 


rlcRangingCont inue 


RlcRangingCont inue, 


— DL 


Ba 


rlcRangingSuccess 


RlcRangingSuccess , 


— DL 


Ba 


rlcPhyCapabilitiesReq 


RlcPhyCapabilitiesReq, 


— DL 


Ba 


rlcPhyCapabilitiesCnf 


RlcPhyCapabilitiesCnf, 


— DL 


Ba 


rlcOtherCapabilitiesReq 


RlcOtherCapabilitiesReq, 


— DL 


Ba 


rlcOtherCapabilitiesCnf 


RlcOtherCapabilitiesCnf, 


— DL 


Ba 


rlcInitializationCmd 


RlcInitializationCmd, 


— DL 


Ba 


rlcDownlinkPhyModeChange 


RlcDownlinkPhyModeChange, 


— DL 


Ba 


rlcUplinkCorrect ion 


RlcUplinkCorrect ion, 


— DL 


Ba 


rlcMeasurement Report Criterium 


RlcMeasurement Report Criterium, 


— DL 


Ba 
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rlcHandoverCmd RlcHandoverCmd, — DL Ba 

rlcConnectionAdditionSetup RlcConnectionAdditionSetup, -- DL Ba 

rlcConnectionChangeSetup RlcConnectionChangeSetup, — DL Ba 

rlcConnectionDeletionlnit RlcConnectionDeletionlnit, — Req->NonReq Ba 

rlcConnectionDeletionAck RlcConnectionDeletionAck — NonReq->Req Ba 



__ ************************************************************^ 

— Messages for Request-Grant (Clause 9) 

************************************************************^ 



RlcBandwidthReq 
caid2 

piggyback2 
caid3 

piggyback3 

} 

This message carries the queue status of three connection aggregates that are 
-- selectable by the AT without any restrictions. CA2 and CA3 are contained in the 
payload, CA1 is represented by the CID and piggyback fields in the header. 



: := SEQUENCE { 

Caid, — 2 byte, common 

Piggyback, — 1 byte, common 

Caid, — 2 byte, common 

Piggyback — 1 byte, common 



RlcQueueStatusReq 



RlcQueueStatusRsp 



SEQUENCE (SIZE (1.. 6)) OF Caid 



SEQUENCE (SIZE (1.. 6)) OF Piggyback 



DL, common 



UL, common 



* * * * * * * * * * * * * * * * * * i 



r******************************** 



Messages for Initialization (Clause 10) 
************************************************************* 



SEQUENCE { 


— DL 






AtMacAddress, 


— 48 


bit, 


common 


Tid, 


— 10 


bit, 


common 


BasicCid, 


— 16 


bit, 


common 


PrimaryCid, 


— 16 


bit, 


common 


SecondaryCid, 


— 16 


bit, 


common 


Caid, 


— 16 


bit, 


common 


Caid, 


— 16 


bit, 


common 


Caid, 


— 16 


bit, 


common 


ApTxP owe r Indication 


— 5 bit, 


common 



RlcRanginglnvitation 
atMacAddress 
tid 

basicCid 
primaryCid 
secondaryCid 
basicCaid 
primaryCaid 
secondary Caid 
apTxP owe r Indication 

} 

RlcRangingReq ::= SEQUENCE { 

rangingStatus RangingStatus 

} 

RlcRangingCont inue 

timingAd just Ranging 
uplinkPower Inc 

} 

RlcRangingSuccess 

timingAd justRanging 
uplinkPower Inc 
initializationStatus 

} 

RlcRangingAck ::= SEQUENCE { 

rangingStatus RangingStatus 

} 

RlcPhyCapabilitiesReq ::= SEQUENCE { 

} 



UL, increasing or adapted power 
— 2 bit 



= SEQUENCE { 
TimingAd justRanging, 
UplinkPower Inc 



DL, adapt power, send Req 
13 bit, common 
6 bit, common 



= SEQUENCE { 
TimingAd justRanging, 
UplinkPower Inc, 
InitializationStatus 



DL, adapt power, send Ack 
13 bit, common 
6 bit, common 
1 bit 



RlcPhyCapabilitiesInf o ::= SEQUENCE { — AT offers its optional cap. 

downlink64QamSupport Downlink64QamSupport, — 1 bit 
uplinkl 6QamSupport Uplinkl 6QamSupport , -- 1 bit 

uplinkTurboEncSupport UplinkTurboEncSupport , -- 1 bit 
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uplinkPowerMaxQpsk 
uplinkPowerMaxl 6Qam 
number SaidSupport 
terminal Type 



UplinkPowerMax, 
UplinkPowerMax, 
Number SaidSupport , 
Terminal Type, 



— 4 bit, 

— 4 bit, 

— 10 bit 

— 1 bit 



common 
common 



pairOf CarrierFrequenciesLow PairOf CarrierFrequencies, 
pairOf CarrierFrequenciesHigh PairOf CarrierFrequencies 



34 bit 
34 bit 



RlcPhyCapabilitiesCnf : : 
downlink64QamUse 
uplinkl 6QamUse 
uplinkTurboEncUse 
up linkPreamble Length 
uplinkPowerMaxQpsk 
uplinkPowerMaxl 6Qam 
initializationStatus 



RlcOtherCapabilitiesReq 

} 



RlcOt her Capabilities Info 



SEQUENCE { 



AP commands what to use 



Downlink64QamUse, 

Uplinkl 6QamUse, 

UplinkTurboEncUse, 

Up linkPreamble Length, 

UplinkPowerMax, 

UplinkPowerMax, 

InitializationStatus 



SEQUENCE { 



bit 

bit 

bit 

bit 

bit, 

bit, 

bit 



common 
common 



SEQUENCE { 



number Up linkConns Support 
number Down linkConns Support 
numberConnAggs Support 
number Conn sPerConnAggSupport 
crSupport 
tripleDes Support 
terminalClCapabilities 



NumberUplinkConnsSupport , 
NumberDownlinkConnsSupport , 
NumberConnAggsSupport , 
Number Conn sPerConnAggSupport , 
CrSupport , 
TripleDes Support , 
TerminalClCapabilities 



— UL 

— 2 byte 

— 2 byte 
2 byte 
2 byte 

— 1 bit 

— 1 bit 

— variable 



RlcOtherCapabilitiesCnf ::= 
number Up linkConnsUse 
number Down linkConnsUse 
numberConnAggsUse 
number Conn sPerConnAggUse 
tripleDesUse 

} 

RangingStatus 
txPowerMax 
txPowerBetween 
txPowerMin 

} 



SEQUENCE { 

NumberUplinkConnsUse, 
Number D own linkConns Use, 
NumberConnAggsUse, 
NumberConnsPerConnAggUse, 
TripleDesUse 



ENUMERATED { 

(0) , 

(1) , 
(2) 



2 bit 



InitializationStatus ::= ENUMERATED { — 1 bit 

initializationContinue (0), -- AT to expect further messaging for init 

initializationFinished (1) — init finished 

} 



RlcInitializationCmd 
init ializationCmd 

} 

I nit ializationCmd 

re jectedFromNetwork 
re jectedFromChannel 
firstlnitialization 
transmissions top 
transmissionReStart 

} 

Up linkPreamble Length 
lengthl 6bit 
length32bit 

} 



= SEQUENCE { 
Init ializationCmd 



ENUMERATED { 

(0) , 

(1) , 

(2) , 

(3) , 
(4) 



ENUMERATED { 
(0) , 
(1) 



DL 

3 bit 



Downlink64QamSupport : := ENUMERATED { 

downlink64QamNotSupported (0), 
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downlink64QamSupported 



(1) 



Uplinkl6QamSupport ::= ENUMERATED { 

uplinkl 6QamNotSupported (0), 



uplinkl 6QamSupported 



Downlink64QamUse : 
downlink64QamNotUsed 
downlink64QamUsed 

} 

Uplinkl 6QamUse : 
uplinkl 6QamNot Used 
uplinkl 6QamUsed 

} 



(1) 



ENUMERATED { 
(0) , 

(1) 



:= ENUMERATED { 
(0) , 
(1) 



ENUMERATED { 



Up linkTurboEnc Support 

uplinkTurboEncNotSupported (0), 

uplinkTurboEncSupported (1) 

} 

UplinkTurboEncUse ::= ENUMERATED { 

uplinkTurboEncNotUsed (0), 

uplinkTurboEncUsed (1) 



TerminalType ::= ENUMERATED { 

terminalFdd (0) , 

terminalHf ddWithTdmAndTdma (1) 

} 

TripleDesSupport ::= ENUMERATED { 

tripleDesNotSupported (0), 
tripleDesSupported (1) 

} 

TripleDesUse 

tripleDesNotUsed 
tripleDesUsed 

} 

TerminalClCapabilities 

Number Up linkConns Support 
Number Down linkConns Support 
NumberConnAggs Support 
Number Conn sPerConnAggSupport 

Number SaidSupport 



ENUMERATED { 
(0) , 
(1) 



OCTET STRING (SIZE (0.. 32) 



variable 



INTEGER (4 . 
INTEGER (5 . 
INTEGER (1 . 
INTEGER (1 . 



. 65535) 
. 65535) 
. 65535) 
. 65535) 



2 byte, 

2 byte, 

2 byte 

2 byte 



incl MAC mgmt conns 
incl MAC mgmt conns 



::= INTEGER (1 . .maxNumber SaidSupport) — 10 bit 



maxNumberSaidSupport NumberSaidSupport : : 


= 1023 










Number Up linkConnsUse 


: := INTEGER (4 . 


. 65535) 


— 2 


byte, 


incl 


MAC mgmt conns 


Number Down linkConnsUse 


: := INTEGER (5 . 


. 65535) 


— 2 


byte, 


incl 


MAC mgmt conns 


NumberConnAggsUse 


: := INTEGER (1 . 


. 65535) 


— 2 


byte 






Number Conn sPerConnAggUse 


: := INTEGER (1 . 


. 65535) 


— 2 


byte 







CrSupport 

crSupportNo 
crSupportYes 

} 



■ ENUMERATED { 
(0) , 
(1) 



************************************ 



Messages for Radio Resource Control (Clause 11) 
************************************************************* 



* * * 


* * 


se 


11 


* * * 


* * 



RlcMeasurement Report Data 
downlinkPhyModeWanted 



: := SEQUENCE { 
DownlinkPhyMode, 



UL 

3 bit, common 
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cnrMeasured 

rxPowerMeasured 

txPowerMeasured 

txPowerMargin 

maxUplinkPhyMode 



RlcDownlinkPhyModeChange 

downlinkPhyModeGranted 

} 

RlcDownlinkPhyModeChangeAck 

down linkPhyModeGr ant edAck 

} 

RlcUplinkCorrect ion 
uplinkPower Inc 
timingAd just Fine 
measurementReportReq 



CnrMeasured, 

RxPowerMeasured, 

TxPowerMeasured, 

TxPowerMargin, 

UplinkPhyMode 



: := SEQUENCE { 
DownlinkPhyMode 



: := SEQUENCE { 
DownlinkPhyMode 



: := SEQUENCE { 
UplinkPower Inc, 
TimingAd jus tFine, 
MeasurementReportReq 



8 bit 

8 bit 

6 bit 

6 bit 

3 bit, 



DL 

3 bit, common 



UL 

3 bit, common 



DL 

6 bit, common 
5 bit, common 
1 bit 



RlcMeasurementReportCriterium : := SEQUENCE { 

periodMeasurement Report At Specific PeriodMeasurement Report 
overwrites periodMeasurementReportGBI 



RlcHandoverCmd : : 

atMacAddress 

newPairOf CarrierFrequencies 
apcld 



SEQUENCE { 



DL 



AtMacAddress, 

PairOf CarrierFrequencies , 

Apcld 



DL, 

3 bit, 



4 8 bit, common 
34 bit 
24 bit 



Apcld 



INTEGER (1 . .16777216) 



RlcHandoverAck 
atMacAddress 

} 



: := SEQUENCE { 
AtMacAddress 



UL 

4 8 bit, common 



MeasurementReportReq ::= ENUMERATED { 

measurementReportRequestedNo (0) , 
measurementReportRequestedYes ( 1 ) 

} 



CnrMeasured 
CnrThreshold 

RxPowerMeasured 
TxPowerMeasured 
TxPowerMargin 



INTEGER (0 . .255) 
INTEGER (0 . .255) 

INTEGER (0 . .255) 
INTEGER (0 . . 63) 
INTEGER (0 . . 63) 



8 bit, granu=0 . 25dB, range= [4,40] dB, absolute 

8 bit, granu=0 . 25dB, range= [4,40] dB, absolute 

8 bit , granu=0 . 2 5dB, range= [-88, -28] dBm, absolute 

6 bit , granu=l . OOdB, range= [-26, +20] dBm, absolute 

6 bit , granu=0 . 2 5dB, range= [ , 12 ] dB, incremental 



PeriodMeasurementReport ::= INTEGER { 

usePeriodicMeasurementReportGBI (0) , 

— only for periodMeasurementReportAtSpecif ic in RlcMeasurementReportCriterium, 

— but not for 

— periodMeasurementReportGBI 
period050 (1), 
periodlOO (2), 
periodl50 (3), 
period200 (4), 
noPeriodicReports (5) 

} 



in RlcGeneralBroadcast Information 
50 ms 
100 ms 
150 ms 
200 ms 



PeriodMeasurementReportGBI ::= PeriodMeasurementReport 
(period050. .noPeriodicReports) 



************************************************************^ 



Messages for Security Control (Clause 12) 



************************************************************* 
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RlcAuthCmd 

} 



:= SEQUENCE { 



DL 



RlcAuthManuf acturerlnf o ::= SEQUENCE { — UL 

manuf acturerX50 9 cert if icate Manuf acturerX50 9 cert if icate 

} 



RlcAuthReq ::= SEQUENCE { 
manuf act urer ID 
atPublicKey 
atX50 9cert if icate 

} 

RlcAuthReply ::= SEQUENCE { 
authKey 
akSeqNo 
akLif eTime 
said 



RlcAuthRe ject ::= SEQUENCE { 
authRe jectErrorCode 
errorlnfoText 



— UL 
Manuf act urer ID, 
AtPublicKey, 
AtX509certif icate 



DL 



AuthKey, 
AkSeqNo, 
AkLif eTime, 
Said 



— DL 
AuthErrorCode, 
ErrorlnfoText OPTIONAL 



RlcAuthlnvalid ::= SEQUENCE { 
authlnvalidErrorCode 
errorlnfoText 

} 



— DL, unsolicited information 
AuthErrorCode, 
ErrorlnfoText OPTIONAL 



RlcTekAl location 
said 
tekl 

teklLif eTime 



SEQUENCE { — DL 

Said, 

Tek, — authentication with HMAC, encrypted with AK 

TekLifeTime, — remaining TEK lifetime 



teklSequenceNumber 

ivParameter 

hmac 

initializationStatus 



TekSeqNo, 
IvParameter, 
HmacKeyedMessageDigest , 
InitializationStatus - 



1 bit 

message send twice with different lifetimes tekl is shorter than the one for tek2 
SEQUENCE { 



RlcTekReq : := 
said 

hmacDigest 

} 



RlcTek2Req ::= RlcTekReq 

RlcTekReject ::= SEQUENCE { 
tekSeqNo 
said 

tekErrorCode 
errorlnfoText 

} 



RlcTeklnvalid : := 
tekSeqNo 
said 

tekErrorCode 
errorlnfoText 

} 

AtPublicKey 

AuthKey 

Tek 

TekLifeTime 
AkLif eTime 



SEQUENCE { 



-- UL, requesting TEK, authentication with HMAC 
Said, 

HmacDigest 



— DL 

TekSeqNo, 

Said, 

TekErrorCode, 
ErrorlnfoText OPTIONAL 



DL, if AT uses invalid TEK for encryption 
TekSeqNo, 
Said, 

TekErrorCode, 
ErrorlnfoText OPTIONAL 



OCTET STRING (SIZE (128)) — 128 bytes 
OCTET STRING (SIZE (20)) — 20 bytes 
OCTET STRING (SIZE (16)) — 16 bytes 



:= INTEGER ( 1.. 1048575) 
:= INTEGER ( 1 . . 1 4 8 5 7 5 ) 



20 bit , granu=lmin, max=2year s 
20 bit, granu=lmin, max=2years 
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TekErrorCode 

AuthlnvalidErrorCode 

TekSeqNo 

AkSeqNo 

HmacDigest 



INTEGER (0 . 
INTEGER (0 . 
INTEGER (0 . 
INTEGER (0 . 



.255) 
.255) 
.3) 
.3) 



:= OCTET STRING (SIZE (20) 



2 bit (instead of 1 byte) 

— 2 bit (instead of 1 byte) 

— 20 byte, HMAC with SHA-1 



AuthErrorCode ::= ENUMERATED { 

reAuthorizationRequested (0), 
permanentRe jection (1) 

} 



HmacKeyedMessageDigest 
Manuf acturerX50 9certif icate 
AtX509certif icate 
KeyReplyMsgAuthent icat ion 
Manuf act urer ID 

IvParameter 

Errorlnf oText 



= OCTET STRING (SIZE (20)) 

= OCTET STRING (SIZE (64)) 

= OCTET STRING (SIZE (64)) 

= OCTET STRING (SIZE (20)) 

= OCTET STRING (SIZE (10)) 

= OCTET STRING (SIZE (8)) 

= IA5String (SIZE (0 .. 128) ) 



64 bit 



************************************************************* 

— Messages for Connection Control (Clause 13) 

************************************************************* 



RlcConnectionAdditionlnit ::= SEQUENCE { 

transactionld Transactionld, — 17 bit 

clid Clid, — 3 bit 

connectionClParameters ConnectionClParameter s , 



variable 



scid 

directionChoice 
arqUsage 



Scid, 

DirectionChoice, 
ArqUsage 



RlcConnectionAdditionSetup ::= SEQUENCE { 
transactionld Transactionld, 
assignedCid AssignedCid, 
assignedCaid AssignedCaid, 
pmAssociation PmAssociation, 
clid Clid, 



— 2 bit 

— variable 

— 2 bit 



17 bit 
16 bit 
16 bit 
1 bit 
3 bit 



connectionClParameters ConnectionClParameters, 



variable 



scid 

directionChoice 

arqUsage 

said 

contentionFlag 
conf irmationCode 



Scid, 

DirectionChoice, 

ArqUsage, 

Said, 

ContentionFlag, 
Conf irmationCode 



RlcConnectionAdditionAck ::= SEQUENCE { 
transactionld Transactionld, 
assignedCid AssignedCid, 
conf irmationCode Conf irmationCode 

} 

RlcConnectionChangelnit ::= SEQUENCE { 



transactionld 

cid 

scid 

directionChoice 
arqUsage 



Transactionld, 

Cid, 

Scid, 

DirectionChoice, 
ArqUsage 



4 bit 
variable 
2 bit 
16 bit 
1 bit 
1 bit 



— 17 bit 

— 16 bit 

— 1 bit 



17 bit 
16 bit 
2 bit 
variable 
2 bit 



RlcConnectionChangeSetup ::= SEQUENCE { 
transactionld Transactionld, 
assignedCid AssignedCid, 



17 bit 
16 bit 
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assignedCaid 

pmAssociation 

scid 

directionChoice 
arqUsage 
contentionFlag 
conf irmationCode 



RlcConnect ionChangeAck 
transaction Id 
assignedCid 
conf irmationCode 



AssignedCaid, 

PmAssociation, 

Scid, 

DirectionChoice, 
ArqUsage, 
ContentionFlag, 
Conf irmationCode 



: : = SEQUENCE { 
Transaction Id, 
AssignedCid, 
Conf irmationCode 



16 bit 

1 bit 

2 bit 
variable 
2 bit 

1 bit 
1 bit 



17 bit 
16 bit 
1 bit 



RlcConnectionDeletionlnit ::= SEQUENCE { 
transactionld Transactionld, 
requestedCid RequestedCid 

} 

RlcConnectionDeletionAck ::= SEQUENCE { 
transactionld Transactionld, 



requestedCid 



(1) 



Conf irmationCode : 
connAccepted (0), 
connRe ject 

} 

RequestedCid 
AssignedCid 

AssignedCaid 

Transactionld 

Clid 



RequestedCid 



ENUMERATED { 



:= DataCid 
:= DataCid 

:= Caid 

:= INTEGER (0 . . 131071) 
:= INTEGER { 



— 17 bit 

— 16 bit 



17 bit 
16 bit 



— 1 bit, request status 



— 16 bit, temp for AT initiated req 

— 16 bit, temp for AT initiated req 

— 16 bit, temp for AT initiated req 

— 17 bit, uniquely assigned by sender 

— 3 bit 



cellBased ( 1 ) , 
packetBased (2) } (0 . . 7) 

ConnectionClParameters ::= OCTET STRING ( SIZE ( . .63) ) 

— 2 bit 



variable, contains VPI for CBCS 



Scid 

periodicRealTime 
realTime 
nonRealTime 
bestEf f ort 

} 



:= ENUMERATED { 

(0) , 

(1) , 

(2) , 
(3) 



PmAssociation ::= 

pmAssociated (0), 

pmNonAssociated (1) 

} 

Said : : = 



ENUMERATED { 



INTEGER (0 . . 65535) 



16 bit 



ArqUsage ::= ENUMERATED { 
noARQ 
onceARQ 
twiceARQ 

} 



(0) , 

(1) , 

(2) 



ContentionFlag : 

contentionReqsNotAllowed (0), 
contentionReqsAllowed (1) 

} 



ENUMERATED { 



1 bit 



DirectionChoice 



CHOICE { 
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uplinkDirection 
downlinkDirect ion 
bidirectional Symmetrical 
bidirect ionalAsymmetrical 



Direct ionDescr, 
Direct ionDescr, 
Direct ionDescr, 
Bidirect ionalAsymmetrical 



Direct ionDescr 

guar ant eedBitRate 
maximumBitRate 
maximumBurstSize 
connect ionMinPhyMode 
transf erDelay 

} 

Bidirect ionalAsymmetrical 
uplinkDirection 
downlinkDirect ion 



SEQUENCE { 

Guar ant eedBitRate, 

MaximumBitRate, 

MaximumBurstSize, 

UplinkPhyMode, — for all DL DirectionDescr 
Transf erDelay 



SEQUENCE { 

DirectionDescr, 
DirectionDescr 



} 

BitRate 

Guar ant eedBitRate 
MaximumBitRate 

Transf erDelay 

MaximumBurstSize 



INTEGER(1 .. 130000) — 17 bit, granu=lkbit / s , max=130Mbit / s 

BitRate 

BitRate 



INTEGER (0 | 5 - .63) — 
INTEGER ( . .255) 



6 bit, granu=lms,max=63ms, 
means Transf erDelay=inf inity 
8 bit, granu=lPduPayload=51byte 
means MaxBurstSize=inf inity 
applies only for data conns 



************************************************************* 

— Common part 

************************************************************* 



Cid 
Tid 
Caid 

AtMacAddress 



BasicCid 
PrimaryCid 
SecondaryCid 
DataCid 



INTEGER (0 . . 65535) 
INTEGER (0 . . 1023) 
INTEGER (0 . . 65535) 
OCTET STRING (SIZE (6)) 



= Cid(10. .1033) 
= Cid(1034 . .2057) 
= Cid(2058. .3081) 
= Cid(3082. .65535) 



-- 16 bit, connection ID 

-- 10 bit, terminal ID 

16 bit, connection aggregate ID 

— 48 bit, MAC-48 address 



Normative specifications for specific Cid values: 



BroadcastCid 

Mult ipleTidBroadcast BasicCid 



— DummyCid 




3 












— RangingCid 




4 












Normative specifications 


for specific 


Tid values 










ContentionWindowTid : : 


= 














EndOfMapTid : : 


= 1 














normal Tid shall be in 


the range [2 


, 1023; 












Piggyback : 


:= INTEGER (0. 


.255) 












UplinkPower Inc : 


:= INTEGER (0. 


.48) 


— 6 


bit, 


granu=0.5dB, range= 


[-20, +4] 


dB 


UplinkPowerlncRangingStart : 


:= INTEGER (0. 


.7) 


— 3 


bit, 


granu=1.0dB, range= 


[ +1, +8] 


dB 


UplinkPowerModChange : 


:= INTEGER (0. 


.32) 


— 6 


bit, 


granu=0.5dB, range= 


[ -8, +8] 


dB 


UplinkPowerMax : 


:= INTEGER (10 


. .20) 




4 bit 


, granu=l . OdB, range 


= [+10, +20 


] dBm 


ApTxPowerlndication : 


:= INTEGER (0. 


.31) 


— 5 


bit, 


granu=ldB, range= [0, 


+31] dBm 




TimingAd justFine : 


:= INTEGER (0. 


.16) 


— 5 


bit, 


granu=0 . 25*symbol, 







range= [-2 , +2 ] symbols , incremental 
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TimingAd just Ranging 



DownlinkPhyMode 
noNewPhyMode 
downlinkPhyModel 
downlinkPhyMode2 
downlinkPhyMode3 
downlinkPhyMode4 



:= INTEGER ( . .8191) 



ENUMERATED { 

(0) , 

(1) , 

(2) , 

(3) , 

(4) , 



downlinkPhyModeFutureReserved ( 7 ) 



UplinkPhyMode : 

undefined 

uplinkPhyModel 

UplinkPhyMode 2 

UplinkPhyMode 3 

uplinkPhyModeFutureRe served 
} 

END 



ENUMERATED { 

(0) , 

(1) , 

(2) , 

(3) , 
(7) 



13 bit, granu=0 . 25*symbol, 

— range} [0, 80] us, absolute value 

— 3 bit 



3 bit 
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Annex C (informative): 
Formats of service primitives 



Table C.1 : Complete ASN.1 description of service primitives 



HAservicePrimitives 




DEFINITIONS 




AUTOMATIC TAGS ::= 




BEGIN 




IMPORTS RlcConnectionAdditionlnit , 


RlcConnect ionAddit ionSet up, 


RlcConnect ionAddit ionAck, 


RlcConnect ionChangelnit , 


RlcConnect ionChangeSetup, 


RlcConnect ionChange Ack, 


RlcConnect ionDelet ion I nit , 


RlcConnect ionDelet ionAck 


FROM HAprotocolPrimitives; 




************************************************************* 


— Lists of service primitives (for connection control) 


************************************************************* 


DlcConnect ionAddit ionlnitReq 




= RlcConnectionAdditionlnit 


DlcConnect ionAddit ionlnit Ind 




= RlcConnectionAdditionlnit 


DlcConnect ionAddit ionReq 




= RlcConnectionAdditionSetup 


DlcConnect ionAddit ion Ind 




= RlcConnectionAdditionSetup 


DlcConnect ionAddit ionRsp 




= RlcConnectionAdditionAck 


DlcConnect ionAddit ionCnf 




= RlcConnectionAdditionAck 


DlcConnect ionChangelnitReq 




= RlcConnectionChangelnit 


DlcConnect ionChangelnit Ind 




= RlcConnectionChangelnit 


DlcConnect ionChangeReq 




= RlcConnectionChangeSetup 


DlcConnect ionChange Ind 




= RlcConnectionChangeSetup 


DlcConnect ionChangeRsp 




= RlcConnectionChangeAck 


DlcConnect ionChangeCnf 




= RlcConnectionChangeAck 


DlcConnect ionDelet ionReq 




= RlcConnectionDeletionlnit 


DlcConnect ionDelet ion Ind 




= RlcConnectionDeletionlnit 


DlcConnect ionDelet ionRsp 




= RlcConnectionDeletionAck 


DlcConnect ionDelet ionCnf 




= RlcConnectionDeletionAck 


END 
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Annex D (informative): 
MSC interpretation guidelines 



This Technical specification contains a number of Message Sequence Diagrams and High Level Message Sequence 
Diagrams. In order to facilitate the reading of the present document this annex gives a light guideline on the way these 
diagrams should be read and interpreted. 

MSC language is a graphical and textual language for the description of the interactions between system components. 
The language is an international standard defined in ITU-T Recommendation Z.120 [8]. Each MSC diagram represents 
one scenario of either a typical or an exceptional exchange of messages between system parts. 

Most common elements are described in the example MSC diagram. In addition the following table list the language 
elements used in the present document. 



T TimerName 



T_TimerName 



opl J 




1 




X 


1 


► 



alt J 


X 




i 






— ► 


i 




Y 










i 



One of the forms of comment. 



The timer symbol with upper part denoting the start and the bottom arrow 
the timer expiry. 



The timer symbol with the bottom arrow denoting the timer expiry. 



The opt keyword indicates optional message sending. 



The alt keyword indicates alternative, in this case either message X or 
message Y is sent. 
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Communicating 
entity 



The box with keyword exc shows 
actions perforemed if exceptional 
conditions are met. The actions 
below are not executed if the 
exceptional conditions are met 
and other way around. 



StartCondilion 





Reject 



local action 



This is a comments 



The activities defined in the 
MSC reference are executed 
zero to m times. 



MediumCondition 



local action 




loop <0, n> LoopMscReference 



i|ew TEK, IV AP 
is chosen 



same TekSeqNo 



Reply 



( /* Said, [TEKn+11 encrypted with AK, IV AP, Hmac, 
TeklifeTime, TekSeqNo, InitializationStatus */ ) 



4 ContinueCondition 



local action 



EndCondition 



ETSI 



203 



ETSI TS 102 000 V1.3.1 (2002-12) 



HMSC diagrams can be productively used to specify more complex patterns of message flows by showing sequences or 
alternatives of atomic MSC scenarios shown only as MSC references. 
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Annex E (normative): 

SDL specification of DLC protocol 



E.1 



The HIPERACCESS SDL model 



The HIPERACCESS SDL model is at this stage a collection of individual models matching more important clauses of 
the present document. There are models for: 

• Radio Resource control, 

• Initialization control, 

• Connection management control, 

• Security control. 

The SDL models are formal in the sense that they are free of any syntactic and semantic errors. As such they are 
suitable for simulation and validation and can serve as a reference implementation or an initial basis for 
implementation. 

The models are integrated with DLC protocol message specification in ASN. 1 . 

Each SDL model has been validated and has been improved until there was no behaviour that is undesired, such as 
deadlocks, livelocks or similar. There are no states where a message could come without a specified transition that 
handles such a case. 

The models are always trying to capture what is going on in reality. In every model, there are simplifications and these 
are no exception. In introduction to each model the most notable simplifications will be highlighted and explained. 



The Radio Resource Control is developed as a closed system, i.e. there are two communicating processes representing 
AP and AT side respectively and there are no other external events that affect the behaviour of the model. In order to do 
that, the use of some SDL constructs needs to be shortly explained. 

• The None event: this is an event that can trigger a transition without any obvious or explained reason. Both AP 
and AT radio resource control entities need to make some decisions based on some measurements and other 
elements. It would be beyond the scope of the model to describe the precise relations between the external 
conditions leading to some action and the actions that come. For modelling such behaviour the None event is 
ideal since it models the decision taken by AP or AT without going into the reasons for such a step. For 
example, one of the None events simulates that some thresholds have been crossed leading to the appropriate 
Rlc message being sent to the AP side. 

• The decision containing the SDL "ANY" operator. The semantic of this is that any of the branches following 
the decision is taken without linking the path with any specific condition. This construct is useful to show all 
possible behaviour alternatives without going into details of why a particular branch was chosen. The 
advantage of using this is that state exploration tools explore possible traces through such decisions thus 
exercising the model in all ways possible. 

• The expression containing "ANY" operator applied to a specific type. For example the application of ANY 
operator to a type Boolean will yield either true or false. There are situations in modelling where some 
message parameters need to be filled but their values do not affect the behaviour in any way (or at least not the 
behaviour of the part that is modelled). It is exactly for such situations that the operator was used. 



E.2 



Radio Resource Control SDL model 
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E.2.1 RRCAP 



process type RRC_AP_PT 



DCL [\ 

mRcportData RlcMcasurcmentReportData, 
dlPhyModcChange RlcDownlinkPhyModeChange, 
dlPhyModcChangeAck RlcDownlinkPhyModcChangcAck, 
ulCorrection RlcUplinkCorrection, 
mCriterium RlcMeasurementReportCritcrium; 

DCL gbi RlcGcncralBroadeastln formation; 

DCL dlPhyMode DownlinkPhyMode := downlinkPhyMode3; 

DCL grantcdDlPhyModc DownlinkPhyMode; 
DCL wantcdDlPhyModc DownlinkPhyMode; 

TIMER T_GBI := GbiDuration; 

TIMER T_end :- cndDuration; 

TIMER T_DownlinkPhyModcChangc := T_DownlinkPhyModeChange Duration; 
TIMER T_UplinkCorrection :- T_UplinkCorrection Duration ; 



Start of RRC 
in the AP 



CD 



dlPhyMode := 
downlinkPhyModc3 



decidePM 



; Decide DL Phy Mode 



(TGBI) 



prepGBI 



: Prepare the content of RlcGencralBroacastlnformationMessage 
■ Just a simplified indication that it needsto be done 



( Starting j 



RRC RLC out 



1(5) 



ralBroadcastlnformation I 



RRC„RLC_in 



^(RRC_UL)J 
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process type RRC_AP_PT 



Starting 



RJ cGcn eral Br oacN. 
cast Information / ■ ■ 
( CALL ptepGBpr 



modelling the GBI 
sending 




/* The s 
RlcGeni 
can 



he sending of |\ 
jencralBroadcastlnformationl 
be done in any state */ 



2(5) 



In all states the the 
RlcGeneral Broadcastlnformation 
may be sent 




newtype RrcDownlinkPhyModeChangeOpcrators \ 
operators prepPMC: DownlinkPhyModc -> RleDownlinkPhyModeChange; 
operator prepPMC; 

fpar dpm DownlinkPhyModc: 

returns pmc RleDownlinkPhyModeChange; 

start; 

task pmcldownlinkPhyModeGranted :- dpm; 
return; 
endopcrator; 
endnewtype; 



newtype RrcMeasurementReportCriteriumOperators N 
Operators prepCri: Integer /* dummy */ -> RlcMeasurementReportCriterium; 
operator prepCri; 
fpar dummy Integer; 

returns mrCri RlcMeasurementReportCriterium; 
start; 

decision any; 

(/* */): task mrCrilperiodMeasurementRcportAtSpccific :- pcriod050; 
(/* */): task mrCrilperiodMeasurementRcportAtSpccific :- pcriodlOO; 
(/* */): task mrCrilperiodMeasurementRcportAtSpccific :- periodl50; 
(/* */): task mrCrilperiodMeasurementRcportAtSpceific :- pcriod200; 
(/* */): task mrCrilperiodMeasurementRcportAtSpecific :- noPcriodicReports; 
enddecision; return; 
endopa'ator; 
endnewtype; 



newtype RlcUplinkCorrcctionOperators Q 
operators prcpULcon - : Integer /* dummy */ -> RlcUplinkCorrcction; ~ 
operator prcpULcorr; 

fpar dummy Integer; 

returns ulc RlcUplinkCorrection; 

start; 

task 

ulcluplinkPowerlnc :- any(UplinkPowcrlnc), 
ulcltimingAdjustFine :- any(TimingAdjustFinc); 
decision any; 

(/* */): task ulc!measurementReportReq :- measure mcntRcportRcquestedNo; 
(/* */): task ulc!mcasurementRcportReq :- measure mcntRcportRcquestcd Yes; 
enddecision; return; 
endopa'ator; 
endnewtype; 
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process type RRC_AP_PT 



3(5) 



5 



Deciding 



R] cMcas urcmc nt 

RcportData 

(mRcportData) 



van tedDlPhyM ode 
RcportData klownlin 
PhyModcWantcd 



^si^NcwPhyMpdt^ 








false 


\ 


true 


granted DIPhyM ode 
- wantedDlPhyModi 




( " 

Deciding 

I i 




: AP decides to allocate AT 
: to another PHY mode region 

: The procedure changes the 

: gran tedDlPhyM ode to noNewPhyMode 

: in case of rejection 



(RlcDownlinkPhy_ j 
ModeChangeSent I 



RJ cDownli nkPhyy 
ModeChangcA^f 
(dlPhyModeCharVAck) 



dlPhyMode := 
dlPhyMode_ 
ChangeAck 
downlinkPhyMode_ 
GrantedAck 



DL Phy Mode 
changed up 



RE 
(T_Dowi 
ModeC 


ET 

linkPhy_ 
hange) 






reset(T_end) 



Exception 

Down 1 inkPhyModc_ 
Change delayed, 
AP retransmitted 



Rl cMcasure me nt^' 
ReportData ^ 
(mReportData) 






t 


RlcDownlinkPrrX 
ModeChangc \ 
(dlPhyModeChan^c) 






SET 

(T_DownlinkPhy_ 
ModeChange) 






RlcDownlinkPhy_ 
ModeChangeSent 



Exception 



DownlinkPhyMode. 
Change delayed 



T_DownlinkPh; 
ModeChangc 






true 


d 


ilPhyModeChange :-- 

prepPMC 
(grantedDlPhyMode 






RIcDownlinkPh^. 
ModeChange y 
(dlPhyModeChan^e) 






SET 

(T_Do™linkPhy_ 
McdcChange) 







\1/ 

(RlcDownlinkPhy_ | 
ModeChangeSent I 



dlPhyMode 
grantedDlPhyMod 



DL Phy Mode 
changed down 



ilPhyModeChange 

prepPMC 
(gran tedDlPhyM ode; 



RlcDownlinkPhyNs 
ModeChange 
(dlPhyModcChan^e) 



reset(T_end) 



sly 

( Dcc,dme j 



Deciding 
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process type RRC_AP_PT 



4(5) 




Rl cMcasurcmc nfReport. 
Criterium 
(mCriterium) 



= measurcmentReport_ 
RcquestedYes 











true 


false 


set(T_Uplink_ 
Correction) 




reset(T_end) 


N 






\ 


/ 


' Measurement 
ReportData_ 
I Requested . 




( m I 





true 


i 


ilPhyModeChange :- 

prcpPMC 
(grantcdDlPhyMode) 






PJcDownlinkPlryV. 
ModcChange y 
(dlPhyModeCliai^c) 






SET 

(T_DowrilinkPriy_ 
ModcChange) 






/ \ 

PJcDownlinkPhy_ 
ModeChangeSent J 





false 




dlPhyMode 


i DL Phy Mode 




= grantcdDlPhyMod 


■ changed down 
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process type RRC_AP_PT 



j / Measurement i 
i | RcportData_ j 
j I Requested / 









RleMeasuremen 
ReportData 4 
( niReportData) 


/ 








reset(T_Uplink_ 
Correction) 






vantedDlPhyMode :- 
ReportData Idownlin 
PhyModcWanted 







^sjoNewPhyMpdt^ 








false 




true 


granted DIPhyM ode 
- wantedDlPhyModi 




( " 

Deciding 

I i 



decide PM 
(bran tcdDlPhyMod 
dlPhyMode) 




j AP decides to allocate AT 
i to another PHY mode region 

i The procedure changes the 

: gran tedDlPhyM ode to noNewPhyMode 

■ in case of rejection 




dlPhyMode 
grantedDlPhyMod 



: DL Phy Mode 
■ changed down 



UPhyModcChange :- 

prepPMC 
[ gran tedDlPhyMode 



UPhyModcChange :~- 

prepPMC 
[gran tedDlPhyMode^ 



RlcDownlinkPhyN 
ModeChange 
(dlPhyModeChaagc) 



5(5) 



• Exception 



T_Uplink_ 
Correction 



RlcUplinkCorrecti: 
(ulCorrection) 



set(T_Uplink_ 
Correction) 



(Measurement i 
RcportData_ 1 
Requested / 



RlcDownlinkPhyN 
ModeChange 
(dlPhyModcChan^c) 



SET 

(T_DownlinkPhy_ 
ModeChange) 



RlcDownlinkPhy_ 
ModcChangeScnt 



( " ) 
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E.2.2 RRC AT 



I RlcGeneralBraidcastliitorniation 



RRC RLC ir 



f(RRC_DL)l 



process type RRC_AT_PT 



TIMER T_\lL'asiii\'iiiL'iilRc]iiirtE)a(;i := T Mca-uiviiiailKt'poilDataDuration 



CD 



dlPhyMode := 
dow nl i n kPl l y M i > lIc 3 



5 



DCL ^ 

mReportData RlcMeasuivinciuReportDaia, 
dlPhyMode Change RleDownlinkPhyModeChange, 
dlPhyModeChangeAck RlcDownlinkPhyModeChangeAck, 
ulCorrection RlcUplin kCorrection , 
mCriterium RlcMeasurementReporiCriterium; 



DCL gbi Rl cGe ne ra 1 Br oad c ast I nforma t i on ; ^ 

DCL dlPhyMode DownlinkPhyMode ;= downlinkPhyMode3: 

DCLgrantedDlPhyMode DownlinkPhyMode; 
DCL wantedDlPhyMode DownlinkPhyMode; 



TIMER T_PeriodMeasurementRepori; ^ 
DCL periodMeasRep Duration: 
TIMER T_end :- endDuration: 



RRC_RLC_out 



^(RRCJJL)] 



1(4) 
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process type RRC_AT_PT 



| Starling after 
■■ first broadcast 
: reception 



RlcGeneral, 
Broadcast_ 
Information 



Reception of general 
broadcast in any state 



(Starting) 



RlcGeneraT / 
Broadcast_ ^ 
Information (gbi^v 



period MeasRep :- 
calcRepDurfgbi ! 
period M e asu r em en t_ 
ReportGBI) 




periodMeasRep :- 
calcRepDurfgbi ! 
:>e ri odMe a su r ement. 
ReportGBI) 



(now+periodMeasRc n. 

T_Period_ 
M easure me n t Re p or t ) 



newtype Period Measurement Report Opera tors |\ 
operators 

calcRepDur: PeriodMeasuremenlReport 
-> Duration; 
operator calcRepDur; 
fpar per PenodMeasurementReport: 
returns dur Duration; 
start; 

task dur :- 0; 

decision per = noPeriodicReports; 
(true): return; 
(false): 

task dur := 

iflper - period050) 

then 50 * FrameDuration 

else 

if (per = periodlOO) 
then 100 * FrameDuration 
else if (per - period 150) 

then 150 * FrameDuration 

else 200 * FrameDuration 

fi 



fi 
fi; 

return; 
enddecision; 
end opera tor; 
end newtype; 



2(4) 



newtype RrcMeasu re men! Report Da taOperators Q 
operators 

prepMdataR: DownlinkPhyMode -> RlcMeasurementReportData; 
changeWanted: DownlinkPhyMode -> Boolean: 
operator changeWanted; 
fpar cpm DownlinkPhyMode; 
returns Boolean; 
start; 

decision any; 

(/* */): return true; 

(/* */): return false: 
enddecision; 
endoperator; 

operator prepMdataR; 
fpar wantedDlPhyMode DownlinkPhyMode; 
returns mReportData RlcMeasurementReportData; 



mReportData! down 1 inkPhy Mod eWan ted := wamedDlPlnMode. 
mReporlDalalciirMeasuivd := anyiCnrMcasured), 
mReportData !r\PowerMcasured := any(R\PowerMeasured), 
mReportData! i. \Pn we rMea.su red := any(TxPovverMeasured), 
mReportData !t\PoweiMaigin := anyfTxPower Margin). 
mReportData !ni;t\UplinkPliyMode := any(UplinkPhyMode); 
return; 
endoperator; 
endnewtype; 
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process type RRC_AT_PT 



i C/(N+I) threshold in 

■ received DL signal crossed 



wantedDlPhyMode 
choosePM(dlPhyMoi e) 



mReporlData :- 
prepMdataR 
(wantedDlPhyMode) 



RlcMeasuremenl. 
ReportData 
(mReportDala) 



> 



SET 

(T_Measurement_ 
ReportData) 



((now+periodMuasRi. ;n. 

T_Period_ 
MeasurementReport) 



JZ 



Rl cMeas u re men t_ 
ReportData_ 



T„Period 
MeasurementRe] 



mReportData :- 

prepMdataR 
(noNewPhyMndc) 



RldVIeasu re merit 
ReportData 
(m ReportData) 



> 



:(now+periodMeasRi p, 

T_Period_ 
Measurement Report) 



JZ 



(Starting) 



Rl cMeas u re m e n tjjlepo rt _ 
Criterium 
(mCriterium) 



|)L'[ ii\IMuasRcp := 



JZ 



c al cRepD ur( mC ri t er i urn ! 
periodMe asu r em en t_ 
ReportAtSpecific) 



Rl cUpl i n kCorr eafTo n 
(ulCorrection) 



'correct UL power 
and timing' 



fhangeWantetr* 
<d!PhyMode> 



mReportDala :- 

prepMdataR 
(noNcwPbyModLM 



RlcMeasuremenl 
ReportData 
(mReportDala) 



3(4) 




- measurementReport_ 
Requested Yes 



wantedDlPhyMode 
choosePM(dlPhyMoi e) 



> 



mReportData :- 
prepMdataR 
wan tedDlPhyMoLk' 



RlcMeasureme ntV 
ReportData \ 
(mReportData) / 



v+periodMeasRe ■>. 
T_Period_ 
VleasurementReport) 



SET 

( T_Mea s u remen t_ 
ReportData) 



(now+periodMeasRi p. 

T_Period_ 
MeasurementReport) 



JZ 



RlcMeasurement_ 
ReportData_ 
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process type RRC_AT_PT 



4(4) 



j Exception 



j Exception 



Deciding 



RlcDownlinkPhy 
ModeChange 
(dlPhyModeChan^ 




dlPhyModcChange 
!downlinkPhy_ 
ModcGr anted 



dlPhyModcChange, 
Ack!downlinkPhy_ 
ModcGr antcdAck :- 



dlPhyModcChange 
!downlinkPhy_ 
ModcGr anted 



dlPhyMode := 



dlPhyModcChange 
!downlinkPhy_ 
ModcGr anted 



RlcDownlinkPhyX^ 

ModcChangcAck 
(d lPhyModeChan^eAck) 



reset 
(T_end) 



Deciding 



: RlcDownlinkPhy_ 

■ ModeChange 

: not arriving in time 



(RlcMeasurcmcnt_ l 
RcportData_ | 
Sent J 



RlcDownlinkPhyy 
ModeChange 
(dlPhyModcChanV) 



T_Period_ / : 
.isurcmcntRcpo/t 



RESET 
(T_Measurcment_ 
ReportData) 



reset 
(T_end) 



Deciding 



TJvIeasuremen 
ReportData 



RlcMeasure merit. 

ReportData 

(mRcportData) 



SET 

(T_Mcasurc men t_ 
Repoi'tData) 



Rl cMcasnrcment_ 
RcportData_ 
Sent 



: RlcUplinkCorrcction 
■ given priority 



Rl cUplin kCorrcyfion 
(ulCorrection) 



reset( 
T_Mcasuremcn t_ 
ReportData) 





false 



mRcportData := 

prcpMdataR 
(noNewPhyModc) 



RleMcasurcmcnt. 

ReportData 

(mReportData) 



sRc p. 



now+ period Mea 
T_Period_ 
MeasurcmentReport 



- mcasuremcntRepoit_ 
Requested Yes 



Deciding 



wantcdDlPhyMode 
choosePM(dlPhyMo< e) 



mReportData : 
prepMdataR 
(wantcdDlPhyMode) 



RleMcasurcmcnt 

ReportData 

(mRcportData) 



SET 

(T_Mcasuremcn t_ 
ReportData) 



:(now+periodMeasRt 3. 

T_Period_ 
MeasurcmentReport) 



Deciding 



RlcMcasurcment_ 
ReportData_ 
Sent 
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E.3 



Initialization control SDL model 



The initialization control model uses several SDL signals that in principle match the protocol messages. However, there 
are two exceptions worth mentioning: 

• RangingGrant signal is used to simulate to the AT side that the AP has given an Ranging grant. 

• EmptyGrant signal is used to simulate to the AP side that there is no content in the place for which an Ranging 
grant was given. 



E.3.1 ICAP 



ft 



Initialization Success 



] 



IC_AP 



Initialize 



process type InitializationAP 



1(12) 




IC_RLC_in 




(DLJC) 



IC_RLCLout 
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process type InitializationAP 



2(12) 



/* Specification of local timers */ 



TIMER T_RangingAck 



:- Ranging AckDurat ion; 



TIMER T_PhyCapabiliticsRcq := PhyCapabiliticsRcqDuration; 
TIMER T_PhyCapabiliticsCnf := PhyCapabiliticsCnfDnration; 
TIMER T_OthcrCapabilitiesReq := OtherCapabiliticsReqDuration; 
TIMER T_OthcrCapabilitiesCnf := OtherCapabilitiesCnfDuration; 



phyCapabiliticsRcq RlcPhyQipabiliticsReq, 

phyCapabiliticsInfo RlcPhyCapabilitiesInfo, 

phyCapabilitiesCnf RlcPhyCapabilitiesCnf, 

otherCapabiliticsReq RlcOtherCapabiliticsReq, 

othcrCapabiliticsInfo RlcOthcrCapabiliticsInfo, 

othcrCapabiliticsCnf RlcOthcrCapabilitiesCnf, 

initializationCmd RlcInitializationCmd; 

DCL rangingRcsponscKind RangingRcsponseKind; 
DCL rangingAckOK RangingAckOK; 
DCL gbi RlcGcncralBroadcastlnformation; 
DCL timingAdjust Timing AdjustRanging; 
DCL powerlnc UplinkPowerlnc; 

DCL phyCapNccdcd Boolean; 
DCL autliNecdcd Boolean ; 
DCL other CapNeeded Boolean; 
DCL iStatus InitializationStatus; 



/* Some special timers used only for modelling |\ 
purposes. These place no normative requirements on the 
implementations */ 

TIMER T_GBI := GbiDuration; 

/* Not mandatory, used in the model to show regular sending of 
RlcGcncralBroadcastlnformation messages */ 

TIMER T_AdjustingDclayGrant :- T_AdjustingDelayGrantDuration; 
TIMER T_SucccssDelayGrant :- T_SucccssDclayGrant Duration; 




DCL 



ranginglnvitation 
rangingRcq 



Rlc Ranginglnvitation, 
RlcRangingRcq, 
RlcRangingContinuc, 

RlcRangin gSuccess, 
RlcRangingAck, 



rangingContinue 

rangingSuccess 

rangingAck 
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process type InitializationAP 



3(12) 



5 



/* Procedures used in AP by the Initialization process 



start APactivities 



* Starting regular broadcast 



prepGBI 



: Prepare the content of RlcGeneralBroacastlnformationMessage 
■ Just a simplified indication that it nccdsto be done 



determineRangingRe spon se 



j A simplified procedure that indicates what 

: kind of responses can be given to RlcRangingRequcst 

: messages 



rangingAckValid 



j A simplified procedure that indicates what 

: kind of responses can be given to RlcRangingAck 

j messages 



PhyCapabilitiesNegotiationNeeded 



: A simplified procedure that models the AP decision to do 
■ PhyCapabiliticsNcgotiation or to skip it 



AuthenticationNeeded 



_ : A simplified procedure that models the AP decision to do 
■ Authentication or to skip it 



OtherCapabilitiesNegotiationNeeded 



: A simplified procedure that models the AP decision to do 
■ OtherCapabilitiesNegoiiation or to skip it 



/* Start of the initialization 
proccess for the first time */ 



start_ 
APactivities 



/* The sending of |\ 
RlcGeneralBroadeastlnformationl 
can be done in any state */ 



c 



Rl cGen er al Br oad\ 
cast In formation >■■ 
< CALL prepGBI^ 





set 






(T_GBI) 




s 


f 
















I 



j In all states the the 

• RlcGeneralBroadcastlnformation 

: may be sent 



: modelling the GBI 
■ sending 



■■• Stay in the same state 
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5 



ncwtypc RlcRangin gin vitation Operators 
operators 

preplnvitation: Integer /*dummy*/ -> RlcRanginglnvitation; 
operator preplnvitation; 
fpar i Integer; 

returns RlcRanginglnvitation; 
start; 

return ( (. atMacAddress, dcfTid, defBasicCid, dcfPrimaryCid, dcfSccondaryCid .) ); 
endoperator; 
endnewtype; 



newtype RlcPhyCapabilitiesCnf Operators 
operators 

prepPhyCapabilitiesCnf: RlcPhyCapabiliticsInfb. InitializationStatus -> RlcPhyCapabilitiesCnf; 
operator prepPhyCapabilitiesCnf; 
fpar in info RlcPhyCapabilitiesInfo, 

is InitializationStatus; 
returns enf RlcPhyCapabilitiesCnf; 
start; 

task cnf!downlink64QamUse :- if (info!downlink64QamSupport - down! ink 64QamNotSupported) 
then downlink64QamNotUscd 
else any(Downlink64QamUse) 

fi; 

task cnf!uplinkl6QamUse :- if (info!i]plinkl6QamSupport - uplink 16QamNotSupported) 
then uplinkl6QamNotUsed 
else any(Uplinkl6QamUse) 

fi; 

task enf luphnkTurboEncUse :- if (infoluplinkTurboEncSupport - uplinkTurboEncNotSupported) 
then uplinkTurboEncNofUscd 
else any(UplinkTurboEncUse) 

fi; 

task cnfluplinkPowcrMaxQpsk :- any(UplinkPowerMax); 
task cnf!up]inkPowcrMaxl6Qam any(UplinkPowa - Max); 
task cnfluphnkPrcamblcLength :- any(UplinkPrcambleLength); 
task enf linitializationStatus := is; 
return; 
endoperator; 
endnewtype; 



ncwtypc RlcOthcrCapabilitiesCnf Operators 
operators 

prepOtherCapabiliticsCnf: RlcOtherCapabiliticsInfo, InitializationStatus -> RlcOthciCapabiliticsCnf; 
operator prepOtherCapabiliticsCnf; 
fpar in info RlcOtherCapabiliticsInfo, 

is InitializationStatus; 
returns enf RlcOthcrCapabilitiesCnf; 
start; 

task cnflnumbcrUplinkConnsUsc :- intblnumberUplinkConnsSupport; /* or smaller */ 
task cnflnumbcrDownlinkConnsUse := intblnumbeiDownlinkConnsSupport; f* or smaller */ 
task cnflnumbcrConnAggsUsc :- infolnumbcrConnAggsSupport; /* or smaller */ 
task cnflnumberConnsPcrConnAggUsc infolnumbcrConnsPerConnAggSupport; /* or smaller */ 
task enf linitializationStatus :- is; 
return; 
endoperator; 
endnewtype; 
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Any signal in the queue 
is removed 



Sending of 
RleRanginglnvitation 



RlcRanginglnvitatSm 
(ranginglnvitation, 



The new initialization 
does not interupt the 
ongoing 
initialization 



Invited, 

V / 













Provide a 
Ranging grant 



RangingGrant 



( " ) (. 



WaitForRcq 



WaitForReq, 
Adjusting, 

RangingAckPending. 
RangingAckReceived 
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Normal 

First Rcq getting through 
^ WaitForReq ^ 



RlcRangingRi 
(rangingRcq) 



]etcrmincRanging_ 
Response 




(rangingRcq, 
ranging. 
Response Kind, 
timingAdjust, 
powcrlnc) 



continueRsp 



rangingContinue 
:- (. timingAdjust, 
power Inc .) 



This signal simulates 
the situation where 
nothing is received 
when the ranging 
grant is given 

In this state this is 
expected as long as 
the transmit! power 
is to low 



rangingSuccess 
:- (. timingAdjust, 
powcrlnc, iStatus .) 



RlcRangingContin 
(rangingContinucJ 



RlcRangingSucccss 
(rangingSuccess) 



(T_Adjusting_ 
DelayGrant) 



(T_Success_ 
DelayGrant) 



M/ Si/ 

( WaitForReq ^ ^ WaitForReq 1 



EmptyGrant 



succcssRsp 



One grant provided 
for the RlcRangingReq 
with adjusted power, 

sent at least 10 frames 
after 

RlcRaneincContinuc 



T_Adjusting_ 
DelayGrant 



RangingGrant 



J ^ Adjusting ^ 



One grant provided 
for the RlcRangingAck, 

sent at least 10 frames 
after 

RlcRangingSuccess 



T_Success_ 
DelayGrant 



RangingGrant 



^ian ging AckPei t J a i ;.: , 



Other signals 
are removed 



WaitForReq 
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7(12) 



Adjusting 

i 



RlcRangingRcq/^ 
(rangingRcq) 








lctcrmin.eRan.gmg_ 
Response 




(rangingReq, 
rangingRcsponscKind, 
timingAdjust, 
power I nc) 











succcssRsp 




T_Adjusting_ 
Del ay Grant 



RangingGrant 



Adjusting 



T_Success_ 
Del ay Grant 



j A grant for RlcRangingReq 

: with adjusted power after 

: RlcRangingContinue was sent 



^angingAckPendin^ 



A grant for RlcRangingAck 
after 

RlcRaneingSuccess was sent 



Exception 

Nothing was received 
when the ranging grant 
is given 



EmptyGrant 



RangingGrant 



^ Adjusting ^ 



The AT is given a 
grant to send a new 
RangingReq with 
increased power 
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IRangingAckPcnding 



RlcRangingAd 
(rangingAck) 



ran^meAckValid 




^rangingAckOK, 



okRsp 



(T_RangingAek) 



(rangingAck, 
rangingAckOK, 
limiti gAdjust, 
power I nc) 



conti nueRsp 



rangingContinue 
:- (. timin gAdjust, 
power Inc .) 



successRsp 



rangingSucccss 
:- (. timin gAdjust, 
powetlnc, iStatus .) 



RlcRangingContiir 
(rangingContinue 



RlcRangingSuccc. 
(rangingSuccess) 



(T_Adjusting_ 
DclayGrant) 



(T_Success_ 
DclayGrant) 



HZ 



^angingAckRcceive^ ^ Adjusting ^ ^ Adjusting ^ 



8(12) 



Exception 
RangingAck lost 



EmptyGrant 



RangingGrant 



: Exception 



: Success is lost and AT 
■ restarted power increase 



RlcRangingRaa/ 
(rangingRcq) \^ 








letermineRanging_ 
Response 




( rangingReq, 

ran gingResponse Kind. 

timin gAdjust, 

powerlnc) 











successRsp 
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(Ran ging Ack_ j 
Received I 



T_RangingAck* 



9(12) 



RlcPhyCapabilitiesJieq 
( phyCapabi litiesRe* 



set(T_Phy_ 
CapabilitiesReq) 




IE 



(PhyCapReq_ | 
Sent I 



authNeeded or 
otherCapNeeded 











true 




false 


iStatus :- 




iStatus :- 


initialization_ 




initialization_ 


Continue 




Finished 



true 




RlcOtherCapabiliMfc 
(otherCapabilitiesBt? 






set(T_Other_ 
CapabilitiesReq) 






iStatus :- 
initialization_ 
Finished 







phyCapNeeded 

false 
authNeeded 

false 

^otherCapNeeded^ 



Initialization Success 



OthcrCapRcq_ 
Sent 
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PhyCapReq_ 
Sent 



RlcPhvCapabilkiCsInfo 
( phyCapabi litiesfafo) 



ihyCapabiliticsCnf : 
r rcpPhyCapabilitiesCi f 
(phyCapabilities 
Info, iptntuo) 



RlcPhyCapabilitieS^irf 
(phyCapabilitiesCni 



RESET 
(JlPhyCapabiliticsRel) 



SET 

(iTPhyCapabilitiesCnh 



PhyCapNeg_ 
Completing 



Exception 



PhyCapabilitiesInfo 
not arriving in time 



T_PhyCapabili<esReq 



RlcPhyCapabilitieS^eq 
(phyCapabilitiesRo< 



set(T_Phy_ 
CapabilitiesReq) 



PhyCapReq_ 
Sent 



rcsct(T_Phy_ 
CapabilitiesReq) 



ETSI 



224 



ETSI TS 102 000 V1.3.1 (2002-12) 



process type InitializationAP 



11(12) 




Exception 

RlcPhyCapabiliticsCnf 
lost AT retransmitting 



RlcPhyCapabilkiCsinlb 
(phyCapabi litiestafo) 



RlcPhyCapabilitie&jif 
(phyCapabi litiesCt^ 



SET 

(|T_PhyCapabilitiesCn 



PhyCapNeg_ 
Completing 



reset(T_Phy_ 
CapabilitiesCnf) 



^ Idle I 
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OthcrCapRcq_ 
Sent 



R] eOthcrCapabLWficsIn to 
(oth crCapabi 1 itiadnfo) 



< therCapabilitiesCnf : 
pOtherCapabilitiesC of 
(othcrCapabilities_ 
"J 



RlcOthciCapabilitltaCnf 
(oth crCapabi litiesQnf) 



RESET 
_OthcrCapabiliticsR( q) 



SET 

(TlOtherCapabilitiesC: 



Exception 



OthcrCapabil itieslnfo 
not arriving in time 



T_OthcrCapabi<3tiesReq 



RlcOtherCapabilitlteRcq 
(oth crCapabi liticsBcq) 



set(T_Other_ 
CapabiliticsRcq) 



(OtherCapNeg_ j / 
Completing I | 



OthcrCapRcq_ 
Sent 



reset(T_Other_ 
CapabiliticsRcq) 



OtherCapNeg_ 
Completing 



Exception 

RlcOtherCapabilitiesCnf 
lost AT retransmitting 



T_OtherCapab«ticsCnf 



Initialization Success 



J (. 



RIcOthcrCapabiJmcsInfo 
(oth crCapabi 1 itieslnfo) 



Rl cOtherCapabi litlteCn f 
(oth crCapabi 1 itiesQnf) 



SET 

(TlOtherCapabilitiesC: 



J I 



OtherCapNeg_ 
Completing 



12(12) 



rcsct(T_Other_ 
CapabilitiesCnf) 



J C 



E.3.2 ICAT 



IC_RLC in 



[(DL_IC)j 



ICLRLC_put 



[<uljq] 



IC out 



^Initialized! 



process type InitializationAT 



/* This page shows process gates as means of 
communicating with other entities */ 



1(9) 
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/* Specification of local variables */ 



DCL 



ranginglnvitation RlcRanginglnvitation, 
rangingReq RlcRangingReq, 



rangingContinue RlcRangingContinue, 
rangingSuccess RlcRangingSuccess, 
rangingAck RlcRangingAck, 



phyCapabilitiesReq RlcPhyCapabilitiesReq, 
phyCapabilitiesInfo RlcPhyCapabilitiesInfo, 
phyCapabilitiesCnf RlcPhyCapabilitiesCnf, 
othcrCapabilitiesReq RlcOtherCapabilitiesReq, 
othcrCapabilitiesInfo RlcOtherCapabilitiesInfo, 
othcrCapabilitiesCnf RlcOthci-CapabilitiesCnf, 
initializationCmd RlclnitializationCnid; 

DCL powerLevel PowerLevel; 
DCL numberOf Attempts Integer; 

DCL synchAquired Boolean; 
DCL paramAquired Boolean; 

DCL gbi RlcGeneralBroadcastlnformation; 

DCL iStatus Initial izationStatus; 

DCL rangingStatus RangingStatus; 
DCL sidReceived Sid; 



TIMER T_PhyCapabilitiesInfo :- PhyCapabilitiesInfoDuration; 
TIMER T_PhyCapabilitiesCnf := PhyCapabilitiesCnfDiiration ; 
TIMER T_OthcrCapabiliticsInfo := OtherCapabilitiesInfoDuration; 
TIMER T_OthcrCapabilitiesCnf := OtherCapabilitiesCnfDuration; 
TIMER T_synhronization :~ SynhronizationDiu'ation; 



syntype PowerLevel = Real constants 20:40 endsyntype; |\ 
synonym minPower PowerLevel = 20; 
synonym maxPower PowerLevel - 40; 
synonym powerStep PowerLevel - 4; 

synonym Synhronization Duration Duration = 10 * FramcDuration; 
synonym sidDefault Sid — 1 ; 
synonym sidlnMemory Sid = 1; 




TIMER T_RangingAck 



:- Ranging AckDurat ion; 
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DL_frequency_scanning 



Simple procedure modelling 
downlink frequency scanning 



UL_and_DL_ 
parameters acqusition 



synchronization_acquisitior 



s etTrans mittPo wer 



adjustPower 



3(9) 



Rccption of general 
broadcast in any state 











I 






RlcGencra]_ jf 


Broadcast 


< 


Information (gbi^v 










\ 


) 
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ncwtypc PdcPhyCapabilitiesInfoOperators |\ 
operators 

sctPhyCapAT: Integer /* dummy */ -> RlcPhyCapabiliticsInfo; 
operator setPhyCapAT; 
fpar int Integer; 
returns info RlcPhyCapabilitiesInfo; 
start; 

decision any; 

(/* */): task info! downlink 64QamSupport :- downlink64QamNotSupportcd; 

(/* */): task info Idownl ink 64QamSupport :- downlink64QamSt.]pportcd; 
enddecision; 
decision any; 

(/* */): task info!uplinkl6QamSupport :- uplinkloQamNotSupported; 

(/* */): task info!uplinkl6QamSupport :- uplinkl6QamSupported; 
enddecision; 
decision any; 

(/* */): task infoluplinkTurboEncSupport :- uplinkTurboEncNotSupported; 

(/* */): task infoluplinkTurboEncSupport :- uplinkTurboEncSupportcd; 
enddecision; 
decision any; 

(/* */): task infolterminalType := terminalFdd; 

(/* */): task infolterminalType :- terminalHfddWithTdmAndTdma; 
enddecision; 

task infoluplinkPowcrMaxQpsk :- any(UplinkPowerMax); 
task info!uplinkPowerMaxl6Qam any(UplinkPowerMax); 
return; 
endoperator; 
endnewtype; 



operators 

setOtheiCapAT: Integer /* dummy */ -> RlcOtherCapabiliticsInfo; 
operator sctOthei - CapAT; 
fpar int Integer; 

returns olnfo RlcOtherCapabiliticsInfo; 

start; 

task 

olnfolnumberUplinkConnsSupport any(NumbcrUplinkConnsSupport), 
olnfolnumberDownlinkConnsSupport :- any(NumbcrDownlinkConnsSuppoit), 
olnfolnumberConnAggsSupport :- any(NumberConnAggsSupport), 
olnfo! numbcrConnsPerConnAggSupport :- anyfNumberConnsPcrConnAggSupport); 
return; 
endoperator; 
endnewtype; 



newtype Sectorldcntification Operators |\ 
operators 

sector Identified : Integer /"'dummy*/ -> Boolean; 
operator sectorldentified; 
fpar dummy Integer; 
returns Boolean; 
start; 

decision any; 
(/* */): return true; 
(/* */): return false; 
enddecision; 
endoperator; 
endnewtype; 
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Start of the ranging proccs 
for the first time 



true 



DL_frcqucncy_ 
_scanning 



'use best 
frequency' 



synchronization_ 

_acquisition 
(synchAqui red) 





UL_and_DL_ 
_ | arameters_acqusiti : i 



This transition is 
performed as soon 
as AT gets into the 
state Idle 



use next 
frequency' 



RlcRanging. 
Invitation 
(ranginglnvitatiol 



AP initiates the : Ignored before PJcRanginglnvitation, 

invited ranging : » i.e. nothing is sent 



RangingGrant 



EmptyGrant 



X 



RangingGrant 



power Level :- 
minPowcr 



rangingStatus :- 
txPowcrMin 



RlcRangingReq 
( (. rangingStatus 



RcquestScnt 



Ignored in this state since 
at least one was received 
already 



RlcRanging. 
Invitation 
(mnginglnvitatiof 
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This means that new 
grant has arrived before 
any response was seen 
as expected in this state 



RcquestSent 



RangingGrant 



setTransmittPower 



RleRangingReq 
( (. rangingStatu 



RequestScnt 



Ignored in this state since 
at least one was received 
already 



RlcRanginglnvridtion 
(ranginglnvitatioi 



RcquestSent 



Rl cRangi ngConjniue 
( rangingContintS 



adj ustPower 
(rangingContinue 
luplinkPowerlnc) 



'adjust timing 1 



RlcRanging Success 
(rangingSuccess\ 



adj ustPower 
(rangingSuccess 
luplinkPowerlnc) 



'adjust timing 1 



j h y 



Exception 

A second grant received after a 
single response message leads 
to renewed increasing of 
power 




adjustPowcr 
(rangingContinue 
luplinkPowerlnc) 



adj ustPower 
(rangingSuccess 
luplinkPowerlnc) 



setTr ansmi ttPowci 



RleRangingReq 
( (. rangingStatus 



Adjusted 



'adjust timing' 



'adjust timing' 



RleRangingReq 
( (. rangingStatus 



I ContinueReceived I SucccssReceived ] I RcquestSent j 

I ; V J v ) 



adjusted TxPower 
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RlcRangingCoi 
(rangingContim 



RlcRangingSucc*res 
(rangingSuccess 1 



Exception 

A second grant received after a 
single response message leads 
to renewed increasing of 
power 



RangingGrant 



rangingAck :- 
(. rangingStatus .) 



RlcRangingAck 
(rangingAck) 



T_RangingAck) 



I RangingComplcting 



Ran gi ngComplc ted 



reset( 
T_RangingAck) 



adjustPower 
(rangingContinue 
luplinkPowerlnc) 



'adjust timing' 



reset( 
T_Ran ging Ack) 



adjustPower 
(rangingSuccess 
luplinkPowerlnc) 



'adjust timing' 



reset( 
T_Ran ging Ack} 



sctTr an s m i ttPowci 



RJcRangingRcq 
(rangingRcq) 



(EE3 (EEE) ( k 1 s:i ) 



I RangingCompleted I 







I 


RlcPhy_ S 
CapabilitiesRcq^ 
( phyCapabi liticsRSQ) 


RlcRanging_ / 
Invitation ^ 
(ranginglnvitationSt 



Ran gingCompleted 



PhyCapabilities_ 
Completing 



RlcOther_ / 
CapabilitiesReq^ 
(otherCapabilitiesl^cq) 



RlcOther_ / 
CapabilitiesReq^ 
(oth erCapabi 1 iticl$ieq) 



hyCapabilitiesInfo 
setPhyCapAT(l) 



RlcPhy_ 
Capabilitieslnfo 
(phyCapabilitiesl 



set(T_Phy_ 
Capabilitieslnfo) 



PhyCapabilities. 
InfoScnt 



J L 



t herCapabilitiesInfo 
setOtherCapAT(l) 



RlcOther_ 
Capabilitieslnfo 
(othcrCapabilitiepfnfo) 



set(T_Other_ 
Capabilitieslnfo) 



(OtherCapabilitics_ j 
InfoSent I 



reset(T_Phy_ 
CapabilitiesCnf) 
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PhyCapabilitics_ 
InfoScnt 



RlcPhyCapabihuCsCnf 
(phyCapabi liticsf 



rcsct(T_Phy_ 
Capabilities Info) 



set(T__Phy_ 
CapabiliticsCnf) 



iStatus :- 
phyCapabiliticsCnf 
linitializationStatus 



PhyCapabilitics_ 
Completing 



j Exception 



: AP retransmitting 
■ Info lost 



RlcRanging_ 
Invitation 
(rnnginglnvitatiol 



reset(T_Phy_ 
Capabilities Info) 



Rl cPhyCapabilittffsReq 
(phyCapabi litiesRcq) 



RlcPhyCapabilitiesSnfo 
(phyCapabi litiesln#>) 



set(T_Phy_ 
Capabiliticslnfo) 



PhyCapabilitics_ 
InfoSent 



j Exception 

: RlcPhy_ 

■ CapabiliticsCnf 

: not received in time 



T_Phy_ 
Capabiliticslnfo^ 




j Exception 

: AP retransmitting Cnf 



initializationContinuc 



^ RangingCompletcdJ ^ 



initializationFinished 



Ranging 



(PhyCapabilities_ 
Completing 



Rl cPhyCapabil h^sCnf 
(phyCapabi litics&rf) 






set(T_Phy_ 
CapabiliticsCnf) 











RlcRanging_ / 
Invitation C 
(ran ginglnvitatiorfcl 






rcset(T_Phy_ 
CapabiliticsCnf) 







J V Inv itcd / 
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I OthcrCapabilities_ 
I InfoSent 



PJcOtherCapabUrtiesCnf 
(other CapabilitiesCnf) 



reset(T_Othcr_ 
Capabilities Info) 



set(T_Other_ 
CapabiliticsCnf) 



iStatus :- other_ 
CapabiliticsCnf! 
initializationStatus 



| OthcrCapabilities_ 
1 Completing 



Exception 



AP retransmitting 
Info lost 



R] cOtherCapabUflicsReq 
(other Capabil itu%Rcq) 



RlcOthcrCapabilitTfclntb 
(oth er Capabil itiesbfro) 



set(T_Other_ 
Capabiliticslnfo) 



OtherCapabil 
InfoSent 



iabilitics_ j 
Sent I 



Exception 

RlcOther_ 
CapabilitiesCnf 
not received in time 



T_Other_ 
Capabil itieslnft? 



RIcRanging 
Invitation 
(ranginglnvitatioi 



rcset(T_Other_ 
Capabiliticslnfo) 



OtherCapabil itics_ 
Completing 



T_Othcr_ 
CapabiliticsCnf 



Ranging 



Exception 

AP retransmitting Cnf 



RlcOther_ 
CapabiliticsCnf 
(other Capabilitie^rif) 



set(T_Other_ 
CapabilitiesCnf) 



I I OtherCapabil itics_ j [ 

I 1 Completing I 1 



RJcRanging_ 
Invitation ^ 
(ranginglnvitationi 






reset(T_Other_ 
CapabiliticsCnf) 







Ranging_ 
Completed, 



RangingGrant 



EmptyGrant 



PhyCapabilities_ 

InfoSent, 

PhyCapabilitics_ 

Completing, 

OtherCapabil itics_ 

InfoSent, 

OtherCapabil itics_ 
Completing 
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E.4 Connection control SDL model 

The Connection Control model is an open system where the two sides AP and AT exchange protocol messages while 
each side communicates with is upper layer using service primitives. In contrast to the protocol messages, the format of 
the service primitives messages is considered informative. Therefore a model is based on the simplification that 
essentially the service primitives related to a particular protocol message are equal in structure to the protocol message. 

The model likely to need some minor modifications following the completion of the Security model. 



E.4.1 CCAP 



(CC_AP_indications), 
(CC_AP_confirmations ) 



cc_ap 



(CC_AP_requests), 
( CC_ AP_res pon se s) 



process type AP_CCtype 



1(5) 



DCL conne cti onAddit ion In it 

DCL conne cti onAddit ion Setup 

DCL conne cti onAddit ion Ac k 

DCL c on ne ct i onC ha ng eln it 

DCL c on ne ct i onC ha ng eSe tu p 

DCL c on ne ct i onC ha ng eAc k 

DCL c on ne cti onD el et ion In it 

DCL conne cti onD el et ion Ac k 



Rlc Connect ionAdditi on I nit ; K 
Rlc Connect ionAdditionSetup; 
RlcConnectionAdditionAck ; 
Rlc Connect ionChange Ini t ; 
Rlc Connect ionCha nge Setup ; 
RlcConnect ionC ha ngeAck ; 
RlcConnectionDeletionlnit; 
RlcConnect ionD el etionAck ; 



TIMER T_Connect ionAdditi on Setup := T_C on necti onAddit ionSetupDuration ; [\ 



TIMER T_ConnectionAdditionAck 

TIMER T_ConnectionChangeSetup 

TIMER T_ConnectionChangeAck - 

TIMER T_ConnectionDeletionInit 

TIMER T_ConnectionDeletionAck 



: = T_Connect ionAdditi onAckDurat ion; 
= T_ConnectionChangeSetupDuration ; 
T_ConnectionChangeAckDuration; 
: - T_Connect ionD el eti onlnitDura ti on ; 
= T_Conne cti onDe le tionAckDurati on ; 



AP_UL 



(UL_CC_mes sages) 



AP DL 



(DL_CC_messages) 
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process type AP_CCtype 



2(5) 



Normal 
AT initiating 

Operational 



RlcConnection/ 
Additionlnit 

(c onn ec ti on Adclit ion In i t) 



Normal 

AP initiated connection 



DlcConnec tion/ 

AdditionReq < ( 

( c onn ec ti on Addit ion S etu p) 



Normal 



Connection_ , 
Addition_ | 
InitReceived j 



DlcConnection/ 

AdditionReq < ( 

( c onn e c ti on Adtlit ion S etu p) 



Exception 

Setup lost 

AT retransmitted 



RlcConnection/ 
Additionlnit 'C 
(connection Additionlni t) 



DlcConnec tiorK 

Addition Initlnd"/ 

(c onn ec ti on Addit ion In i t) 



RlcConnectioik 

AdditionSetup / 

(c onn ec ti on Addit ion S etu p) 



RlcCon nectioik 

AdditionSetup / 

(c onn ec ti on Addit ion S etu p) 



SET 
(T_Connection_ 
AdditionSetup) 



SET 
(T_Connection_ 
AdditionSetup) 



Connection_ 

Addition_ 
InitReceived 



\ Connection 
I Addition_ 
AckPending ' 



, Connection_ 

Addition_ 
I AckPending 



Connection_ \ 
Addition_ 1 
AckPending 



- Normal 



Connection_ 
Addition_ 
AckPending 



RlcConn ec tion/ 

AdditionAckx' 

(c onnection Addition Ack) 



RESET 
(T_Connection_ 
AdditionSetup) 



DlcConnec tiorK 

AdditionCnf ~) 

(c onnection Addition Ack) 



SET 
(T_Connection_ 
AdditionAck) 



,' Connection_ 
Addition_ 
Completing 



Exception 
Ack not arriving 



T_Connectioi 
AdditionSetui 



Exception 

Setup lost 

AT retransmitted 



Rlc Con nect ion/ 7 
Additionlnit < 
(connection Additionlnit) 



RlcCon nectionx RlcConnectioil: 
AdditionSetup / AdditionSetup 
(connection A ddit ion S etu p )(connectionA dd it ion Setu p) 



SET 
(T_Connection_ 
AdditionSetup) 



SET 
(T_ Connect ion _ 
AdditionSetup) 



( Connection_ \ 
I Addition_ 
\ AckPending J 



i — ^ — 

, Connection_ 

Addition_ 
v AckPending 



- Normal 



\ Connection_ 
I Addition_ 
\ Completing 



T_Connection; 
AdditionAck^ 




connAccepted 



Exception 



AT retransmitted 



connReject 



f ] ( 

IConnectionReadyi | Operational 

V / \ 



RlcConnection/ 
AdditionAckC 
(c onn ec ti on Addit 






SET 
(T_Connection_ 
AdditionAck) 


\ 


/ 



Connection 
Addition_ 
Completing J 



ETSI 



236 



ETSI TS 102 000 V1.3.1 (2002-12) 



process type AP_CCtype 



3(5) 



Normal 

AT initiated connection 
change 

| C on ne c ti on Re ady I 







RlcConnection/ 
Chang elnit <C 
(c onn ec ti on Ch ant 






DlcComiec tiohx 
Chang e In it Ind ) 
(c onnectionCb^ng 


\ 


/ 



Norma 1 



AP initiated connection 
change 



DlcCoimection/ 
ChangeReq \ 



Connection_ \ 
Change_ J 
InitReceived j 



RlcConnectionx 
ChangeSetup J 
(connecti onQiang eS et up ) 



SET 
(T_ Connection, 
ChangeSetup) 



/ Connection_ \ 
| Change_ | 
\ AckPending / 



Normal 

AT initiated connection 
change 



Connection_ \ 
Change_ | 
InitReceived / 



DlcConnection 
ChangeReq 
(connectionChaXg eSetup) 



Exceptions 

ChangeSetup lost 
AT retransmitted 



RlcConnectioi 
Changefoit 
(c onn ec ti on Ch iing eln it ) 



Exception 

AP initiated 
delete 



Exce ption 

AT initiated 
delete 



RlcConnection/ , 
Deletionlnit 

(c onn ec ti on Delfetj on Ini t) 



Dl cC o nn ec tio w_ 
I3eletionReq < C 
(connecti on Deleti on Ini t) 



RlcConnectioiK 
ChangeSetup ) 
(connecti on Qitng eS et up ) 

SET 
(T_Connection_ 
ChangeSemp) 



Connection_ 

Change_ 
AckPending 



( Connection_ \ 
I Change_ 1 
\ AckPending J 



DlcConnectionv 
Deletionlnd / 
(connec tionEjeletionlnit) 



Connection_ , 
Deletion_ | 
Received / 



Rlc Connections, 
Delet io nlni t ) 
(connecti on EteletionlriO 



SET 
(T_Connection_ 
Eteletionlnit) 



VIA AP DL 



Connection_ 

De letion_ 
AckPending 
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process type AP_CCtype 



4(5) 



Normal 



, Connection_ \ 
j Change_ | 
\ Ack Pending 



RlcConnection/ 

Change Ack "C 

(c oimecdonQiatigeAck) 



RESET 
(T_Connection_ 
ChangeSetup) 



DlcConnectioiK 

ChangeCnf ~> 

(c onn ec ti on Cftang eA ck) 



Exceptions 
Ack not arriving 




Exception 

ChangeSetup lost 
AT retransmitted 



Exce ption 

AP initiated 
delete 



Exception 

AT initiated 
delete 



RlcConnection/ , RlcConnection/ 
Changelnit \. ~ Deletionlnit \ 

(c onn ec ti on Ch aqg eln it ) (coimecti on Deletionlnit) 



DlcCoruiection/ 

DeletionReq \ 

(c onn ec ti on Delet ion Ini t) 



RlcConnectiorK RlcConnectiorK DlcConnectiork 

ChangeSetup ) ChangeSetup y Deletionlnd / 

(connectionCjvangeSetup) (connection ChangeSetup) (coimectionDeletionlnit) 



SET 
(T_Connection_ 
ChangeSetup) 



SET 
(T_ Connection, 
ChangeSetup) 



RESET 
(T_Connection_ 
ChangeSetup) 



RlcCon nectionX 
Deletionlnit / 
( c onn ec ti on Dele t ion I ni t) 
VIA APlDL 

_£_ , 

RESET 
(T_Connection_ 
ChangeSetup) 



SET 
(T_Connection_ 
Change Ack) 

, — ^ — 

\ Connection_ 
I Change_ 
I Completing 



( Connection_ 
I Change_ 
AckPending 



( Connection_ 
I Change_ | 
I AckPending 



Connection_ \ 
Deletion_ | 
Received j 



SET 
(T_Connection_ 
Deletionlnit) 



Connection_ 
Deletion_ 
AckPending 



- Normal 



Connection_ 

Change_ 
Completing 



T_Connectioii; 
Change Ack ^ 



connec'tionChangeAckl 
c^n^irmtionPod' 



connAccepted 



It is assumed that in case 
of rejection old connection 
staysasitwas 



connReject 



[ConnectionReadyi - jConnectionReadyj 



Exce ption 



AT retransmitted 



RlcConnection/ 
ChangeAck <C 
(connectiondans 






SI 

(T_Con 
Chant 


;t 

nection_ 
eAck) 


\ 


/ 



Exception 

AP initiated 
delete 



Exception 

AT initialed 
delete 



C Connection_ 
Change_ 
Completing 



RlcConnection/ DlcConnection/ 
Deletionlnit "C " DeletionReq'C 

(connectionDeletionlnit) (connectionDeletionlnit) 



Dl cCo miectio iK 
Deletionlnd / 
(connectionP eleti on Ini t) 



RlcConnectiorK 
Deletionlnit y 
(conn ecti on Q elet ion Ini t) 



RESET 
(T_Connection_ 
ChangeAck) 



VIA AP 


_DL 


RESET 
(T_Connection_ 
ChangeAck) 






SI 

(T_Con 
Deleli 


;t 

iection_ 
on In it) 



/ Connection_ A 
I Deletion_ 
\ Received j 



I Connection_ ^ 

Deletion_ 
\ AckPending 
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process type AP_CCtype 



5(5) 



Normal 



AP initiated connection 
deletion 



IConnecti on Ready 

\ ' 



DlcConnec tion/ 

DeletionReq "C 

(c onn ec ti on De letion In i t) 



Normal 



AT initiated connection 
deletion 



RlcConnection/ 

Deletionlnit \ 

(c onn ec ti on Deleti on Ini t) 



Normal 



/ Connection_ 
Deletion_ 
Ack Pending 



V 



RlcConnection/ 

DeletionAck \ 

(c onn ec ti on Deleti on Ack) 



Exception 



T_Connectioi 
Deletionlnit 



RlcConnectiorK 
Deletionlnit / i 
(c onn ec ti on Deleti on In i t) 



SET 
(T_Connection_ 
Deletionlnit) 





Connection_ 

Deletion_ 
Ack Pending 



VIA AP DL 



DlcCoiinectioiK 

Deletionlnd / 

(c onn ec ti on Dele ti on Ini t) 



Connection 
Deletion_ 
Received J 



RESET 
(T_ Connection, 
Deletionlnit) 



DlcConnectiohx 

DeletionCnf ~)> 

(c onn ec ti on Dele ti on Ack) 



SET 
(T_ Connection, 
Deleti onAck) 



Connection_ 
Deletion_ 
Completing 



RlcConnectionX 
Deletionlnit ) 
( c onn e c ti on Dele t ion I ni t) 



VIA AP 


_DL 


SET 
(T_Connection_ 
Deletionlnit) 


\ 


/ 



Connection_ 
Deleti on_ 
Ack Pending 



Normal 



Connection_ 
Deletion_ 
Received 



DlcConnec tion/ 

DeletionRsp ^ 

(c onn ec ti on Deletj on Ack) 



Exception 

Ack delayed, 
AT retransmitted 



RlcConnection/ 

Deletionlnit \ 

(c onn ec ti on Delfeti on Ini t) 



Normal 



RlcConnectiorK 

DeletionAck > VIA AP_DL 

(c onn ec ti on Deleti on A ck) 



( Connection, 
I Deletion_ 
Completing 



Connection_ 
Deletion_ 
Completi ng 



T_ Connection; 
DeletionAck x 









VIA AP 


_DL 


SET 








SET 


(T_Connection_ 








(T_Connection_ 


DeletionAck) 








DeletionAck) 


\ 


/ \ 


/ \ 




/ 



Connection_ 
Deletion_ 
Received 



Operational 



Exception 
Ack lost 

AT retransmitted 



RlcConnection/ 

Deletionlnit =C 

( c onn e c ti on De leti on I ni t) 



RlcConnectionX 

DeletionAck / 

( c onn e c ti on Dgle t ion Ac k) 



Connection 
Deleti on_ 
Completing j 
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E.4.2 CC AT 



cc at 



(CC_AT_iiidications), 
(CC_AP_confirmatioas) 



(CC_AT_requests), 
(CC_AT_responses) 



AT 

^(UL_CC_messages 

at^ 

\ 

(DL_CC_messages 



UL 



DL 



process type AT_CCtype 



1(5) 



DCL conne cti on Add it ionlnit Rl cConne cti onAddit ion In it ; [\ 

DCL conne cti onAddit ionS etup Rl cConnecti onAddit ion Set up ; 

DCL conne cti onAddit ionAck Rl cConnecti onAddit ionAck ; 

DCL conne cti on Chang el nit Rl cConnec ti onChangelnit ; 

DCL conne cti on Changes etup Rl cConnecti onChangeSetup ; 

DCL conne cti on Chang eAck Rl cConnec ti onC hang eAck; 

DCL conne cti on Del et ionlnit Rl cConnecti onDel et ion Ini t ; 

DCL conne cti on Del et ionAck Rl cConnecti onDel et ionAck ; 



TIMER T_ConnectionAdditionInit := T_Connecti onAddit ion Ini tDur at ion ; [S 
TIMER T_ConnectionAddit ionAck := T_Connecti onAddit ionAckDu rati on; 
TIMER T_ConnectionChangeInit : = T_Connecti onChangel nitDur at ion; 
TIMER T_ConnectionChangeAck := T_ConnectionChangeAckDuration; 

TIMER T_ConnectionDeletionInit := T_Connecti onDel et ion Ini tDur at ion ; 
TIMER T_ConnectionDeletionAck :» T_Conne ct ionDe le ti onAckDur at ion; 



Operational 
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process type AT_CCtype 



2(5) 



Normal 



AT initiated connection 
addition 



Operational 



DlcConnec tion/ 
Addition Init&eq 
(c onn ec ti on Adoit ion In i t) 



RlcConnectiorK 

Addition Init ~/ 

(c onn ec ti on Addit ion In i t) 



Normal 



AP initiated connection 
addition 



RlcCon nection/ 

AdditionSetuj) 

( c onn ec ti on Adftit ion S etu p) 



DlcConnec tiorK 

Additionlnd ~/ 

(c onn ec ti on Addit ion S etu p) 



- Nonnal 



/ Connection_ 
| Addition_ 
\ SetupPending 



RlcCon nection 
AdditionSetup^ 
(connect! on Addition Se tu p) 



RESET 
(T_ Connect ion _ 
Additionlnit) 



Exceptions 



T_Connectio) 
Additionlnit 



RlcCon nectioik 

Additionlnit / 

(c onn ec ti on Add it io nl ni t) 



SET 
(T_Connection_ 
Additionlnit) 



Connection_ 
Addition_ 
\ SetupPending 



( Connection 
I Addition_ 
SetupReceived ' 



Dl cCo nn ec tioiK 
Additionlnd ~y 
(connection A ddit ion Se tu p) 



*k — 

l Connection_ 
Addition_ 
SetupReceived 



SET 
(T_Connection_ 
Additionlnit) 



, Connection_ \ 
I Addition_ 
SetupPending ,' 



Normal 



, Connection_ 
| Addition_ 
SetupReceived 



DlcConnec tion 
AdditionRsp^ 
(c onn ec ti on AdtHt ion Ack ) 



RlcConnectiorK 

Addition Ack y 

(c onn ec tion Addition Ack) 



SET 
(T_Connection_ 
AdditionAck) 



( Connection_ 
I Addition_ 
Completing 



Exce ption 

Ack delayed, 
AP retransmitted 



RlcConnection/ 
AdditionSetuji 
(connection Addit ion Setu p) 



Connection_ ^ 
Addition_ 
SetupReceived j 



- Nonnal 




t ion Ad di lionAck! 
irmationC 



connAccepted 



ConnectionReady, | Operational i 

' J V I 



Exception 
Ack lost 

AP retransmitted 



connReject 



RlcCon nectioix 
AdditionSetif 
(c onn ec ti on Addi^ io nS etu p) 



RlcCon nectiorix 

AdditionAck y 

( c onn ec ti on Add it io nAck ) 



SET 
(T_Connection_ 
AdditionAck) 



Connection_ \ 
Addition_ 
Completmg J 
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process type AT_CCtype 



3(5) 



Normal 

AT initiated connection 
change 



Norma 1 

AP initialed connection 
change 



[Con necti onReadyj 



DlcConnee tion/ 
ChangeMtRei 



Change In it / 



SET 
(T_Connection_ 
Changelnit) 



( Connection 
I Change_ 
v SetupPending 1 



Rlc Connect ion/; 
ChangeSeturiC 
(conn ecti on Ch ang 






DlcConnee tion\ 
Changelnd / 
(conn ecti on Qtang 




/ 



I Connection_ 
Change_ 
SetupReceived 



- Normal 



, Con necti on_ 
I Change_ 
\ SetupPending 



RlcConnection 
Chang eSetup\ 
(c onn ec ti on Ch arig eS et up ) 



RESET 
(T_Connection_ 
Changelnit) 



DlcConnee tiorK 

Changelnd ) 

(c onnect i on Qrang eS et up ) 



, Con necti on_ 
I Change_ 
SetupReceived 



Exception 

RlcConnection_ 
Chang eSetup 
not arriving 



T_ Conn ecti on£ 
Changelnit \ 






RlcCon nectionx 
Changelnit } 
(c onn ec ti on Qraiig 






SET 
(T_Connection_ 
Changelnit) 


\ 


/ 



Exception 

AP initiated 
delete 



Exception 

AT initiated 
delete 



RlcConnection/ , DlcCoimection/ 

Deletionlnit <C " DeletionReq'C 

(c onn ec ti on Deleti on Ini t) (c onn ec ti on Deleii on Ini t) 



RESET 
(T_Connection_ 
%) Changelnit) 



RlcCon nectioi 
Deletionlnit 
(connecti on D ^feti on 



VIA AT_UL 
Iiiit) 



DlcConnectiorK 

Deletionlnd ) 

(c onn ec ti on Qeleti on Ini t) 



, Connection_ \ 
| Change_ 1 
SetupPending j 



( Connection_ 
I Deletion_ 
\ Received 



SET 
(T_ Connection, 
Deletionlnit) 



RESET 
(T_ Connection, 
Changelnit) 



Connection_ 

Deletion_ 
Ack Pending 
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process type AT_CCtype 



4(5) 



- Normal 



Connection_ 

Change_ 
SetupReceived 



DlcComiection/ 

Chang eRsp C 

(c oimection Chang eAck) 



RlcCormectiorK 

Chang eAck } 

(c onnecti on Chung eAck) 



SET 
(T_Connection_ 
Change Ack) 



Exception 

Ack delayed, 
AP retransmitted 



RlcCon nection/ 
Change Setups 
(coimection Chang eSet up) 



Exception 

AP initiated 
delete 



Exception 

AT initiated 
delete 



RlcConnection/ , DlcConnectioni 
Deletionlnit \ ^ DeletionRsp'C 

(connect! onDelBtionlnit) (connectionDetetionAck) 



DlcConnectiorK I RlcCon nect ion\ 

Deletionlnd ~y> ; Deletionlnit y — — via AT_UL 

(conn ecu on Deletionlnit) (connectionDpletionlnit) 



SET 
(T_ Connection, 
Deletionlnit) 



Connection_ \ 

Change_ 
Completing j 



, Connection_ A 
I Change_ 
SetupReceived j 



j Connection_ 
I Deletion_ 
\ Received 



Connection_ 

De letion_ 
AckPending 



- Normal 



Connection_ 

Change_ 
Completing 



T_Connectioii; 
Chang eAck ^ 



Exception 
Ack lost 

AP retransmitted 



connection ChangeAck | 
c^ni^inationPod'' 



connAccepted 



It is assumed that in case 
of rejection old connection 
staysasitwas 



connReject 



[ConnectionReadyi - jConnectionReadyJ 



RlcCon nect ion/ 
Change Setups 
(connection Chans 






RlcCon nectiorK 
Change Ack / 
(c onn ec ti on Oram 






SET 
(T_Connection_ 
Change Ack) 


\ 


/ 



Exception 

AP initiated 
delete 



RlcCon nect ion/ 
Deletionlnit \ 



I Connection_ A : 
| Change_ 1 
, Completing J 



Exce ption 

AT initiated 
delete 



DlcConnecdon/ 
DeletionRsp\ 



(connection Deletionlnit) (connectionDeletionAck) 



DlcConnectiorK RlcConnectiork 
Deletionlnd / Deletionlnit / — 

(connection D ele ti onlni t) (connectionQ efeti on Ini t) 



via AT_UL 



RESET 
(T_Connection_ 
Change Ack) 



RESET 
(T_Connection_ 
ChaiigeAck) 






SI 

(T_Con 
Deleti 


2T 

r iection_ 
onlnit) 



Connection_ \ 
Deleti on_ 
Received J 



f Connection_ A 
, Deleti on_ | 
\ AckPending 
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process type AT_CCtype 



5(5) 



Normal 



AT initiated connection 
deletion 



IConnecti on Ready 

\ ' 



DlcConnec Hon/ 

DeletionReq "C 

(c onn ec ti on De letion In i t) 



Normal 



AP initiated connection 
deletion 



RlcConnection/ 

Deletionlnit \ 

(c onn ec ti on Deleti on Ini t) 



Normal 



/ Connection_ 
Deletion_ 
Ack Pending 



V 



RlcConnection/ 

DeletionAck <( 

(c onn ec ti on Deleti on Ack) 



Exception 



T_Connectioi 
Deletionlnit 



RlcConnectiorK 
Deletionlnit / 



VIA AT 


_UL 


SET 
(T_Connection_ 
Deletionlnit) 




/ 



Connection_ 

Deletion_ 
Ack Pending 



DlcCoimecuoiK 

Deletionlnd / 

(c onn ec ti on Dele ti on Ini t) 



Connection 
Deletion_ 
Received J 



RESET 
(T_ Connection, 
Deletionlnit) 



DlcConnectioiK 

DeletionCnf ~)> 

(c onn ec ti on Dele ti on Ack) 



SET 
(T_ Connection, 
DeletionAck) 



Connection_ 
Deletion_ 
Completing 



RlcConnectionx 
Deletionlnit ) 
( c onn e c ti on Dele t ion I ni t) 



VIA AT 


_UL 


SET 
(T_Connection_ 
Deletionlnit) 


\ 


/ 



Connection_ 
Deletion_ 
Ack Pending 



Normal 



Connection_ 
Deletion_ 
Received 



DlcConnec tion£ 

DeletionRsp ^ 

(c onn ec ti on Deletj on Ack) 



Exception 

Ack delayed, 
AP retransmitted 



RlcConnectioi 
Deletionlnit ' 
(c onn ec ti on Delfetj on Ini t) 



Normal 



RlcConnectiorK 

DeletionAck > VIA AT_UL 

(c onn ec ti on Deleti on Ask) 



( Connection, 
I Deletion_ 
Completing 



Connection_ 
Deletion_ 
Completi ng 



T_ Connection; 
DeletionAck x 









VIA AT 


_UL 


SET 








SET 


(T_Connection_ 








(T_Connection_ 


DeletionAck) 








DeletionAck) 


\ 


/ \ 


/ \ 




/ 



Connection_ 
Deletion_ 
Received 



Operational 



Exception 
Ack lost 

AP retransmitted 



RlcConnection/ 

Deletionlnit =C 

( c onn e c ti on De leti on I ni t) 



RlcConnectionx 

DeletionAck } 

( c onn e c ti on Dgle t ion Ac k) 



Connection 
Deleti on_ 
Completing j 
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E.5 Security control SDL model 

The current version of SDL model for security control is provided for information since the validation of the model is 
still in progress. 

E.5.1 AP SC 



I terminateAk, I 
' 1 gctAkTimeLeft 



akt 



AkExpircd, I 
AkTimeLeftJ 



process type AP_Authorization 



1(7) 



PKM 



^(UL_PKM_AUTH)J 



£(DL_PKM_AUTH)] 



timeLeft 



imported procedure akSeqNoConfirmed 
fpar AkSeqNo; 
returns AkConfirmcd: 



stopFirstAkTiming 



A 

stopAkTiming 
\ 



^(lromTEKap)J 
^^(toTEKapjJ 



child 
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process type AP_Authorization 



2(7) 



DCL authManufacturcrrntb RlcAuthManufacturcrlnfo; 
/» fields: 

manufacturer X509certiticate */ 

DCL authReq RlcAuthReq; 
/» fields: 

AtX509ccrtificate, AtPublicKey, Manufacturerld */ 

DCL authReply RlcAuIhReply; 
/* fields: 

AuthKey, AkSeqNo, AklifeTime, Said »/ 

DCL authReject RlcAuthReject; 
/» fields: 

AuthErrorCode, ErrorInfoText[Optional]*/ 

DCL authlnvalid RlcAuthlnvalid: 
/» fields: 



authlnvalidErrorCode 
errorlnfoText OPTIONAL »/ 



TIMER T_AuthCmd := T_AuthCmdDuration; 




DCL tckReq 
/* fields: Said */ 



RlcTekReq; 



TIMER T_AuthRequestRetry; 



DCL akSeqNo 
DCL said 



Said; 



AkSeqNo; 



DCL akRecord 
DCL akList 
DCL akTimeLelt 



AkRecord; 
AkList; 
Integer; 



exported procedure SaidApInvalid; 

start; 

return; 
endprocedure; 



DCL isAkln valid 



IsAklnvalid :- maxAklnvalid; 
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process type AP_Authorization 



3(7) 



akSeqNo :- 
any(AkSeqNo) 



set( 

T_AuthCmd) 



SaidApIn valid 



stopAkTiming 
(akList) 



: In case Manlnfo 


■ is lost 












RlcAuthRcq / 




(authRcq) 











RlcAuthManufa^, 
cturcrlnfo 
(authManufa_ 
cturcrlnfo) 



I 



Privacy initialization 
begins with the AP 

sending the AT an 
authentication command 
(PJcAuthCmd) message. 



^ ManlnfoWait J 



Added so that 
all signals received 
while in this state 
are discarded 



Exception 



No Manlnfo from the 
terminal 



AP resends 
RlcAuthCmd 



set( 

T_AuthCmd) 



( AuthWait 1 ^ 



Waiting before a 
new authorisation 
may be initiated 







AuthRejectWait 














T_Auth_ / 
RequcstRetry 









^ AuthRejectWait j ^ Idle j 
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process type AP_Authorization 



4(7) 



RlcAuthRcq 
(authReq) 




set(now + 
AuthRcjectWait_ 
Timeout, 
r_AuthRequcstRetry 



AuthRcjcctWait 



A 



akRecord := 
prcpAkRccord 
(defAuthKey, 
dcfAkLifcTimc, 
akSeqNo) 







authRc 
prepAu 
( authReq . 


ply := 
h Reply 
akRecord) 



RlcAuthRcply 
(authReply) 



> 



AKtiming 
(dcfAkLifeTime) 



akRccordlakPid 
:= offspring 



akList :- addAk 
(akList, akRecord) 



said :- authReply 
!said 



Authorized 
(said, authReply! 
akSeqNo) 



\1/ 

f Authorized 



Exception 



No RlcAuthRcq from the 
terminal 



AP resends 
RlcAuthCmd 



set( 
T_AuthCmd) 
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process type AP_Authorization 



5(7) 



Reauthorization 



RlcAuthReq 
(authRcq) 



reset( 
T_AuthCmd) 




not Authorized 




akTimeLeft ;= CALL 
timeLcft(akList 
(lst)lakPid) 



rcAuthorization_ 
Requested 




permanent_ 
Rejection 



stopAkTiming 
(akList) 



'disab 
forwa 
of AP 


eall 
rding 
traffic' 






stopAk 
(aid 


Timing 
ist) 



StopTek 



StopTek 



RlcAuthReject 
(authRcjcct) 



akSeqNoConfirmed 
(akSeqNo) 



akNotConfnnied 



akRecord := 
prepAkRecord 
(defAuthKey, 
akTimeLeft + 
defAkLifcTime. 
akSeqNo) 



RlcAuthReject 
(authRcjcct) 



sct(now + 
AuthRcjectWait_ 
Timeout, 
r_AuthRcquestRctry 



^ AuthRcjcct Wait ^ ^ ^ 



akSet 
incAkSN 


No := 
akSeqNo) 











authRe 
prepAu 
(authRcq, 


ply- 

hReply 
akRecord) 



akRecord := 
prepAkRecord 
(defAuthKey, 
akTimeLeft + 
defAkLifcTime, 
akSeqNo) 







authRe 
prepAu 
(authRcq, 


ply;= 

hReply 

akRecord) 



RlcAuthReply 
(authRcply) 



RlcAuthReply 
(authReply) 



isAkln valid :- 
decr(isAldn valid) 







stopF 
AkTimin 


irst_ 
g(akList) 






akLi 
remo 
(akl 


•t ■- 
veAk 
ist) 
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process type AP_Authorization 



• Reauthorization 



6(7) 




RlcAuthReq 
(authRcq) 




not Authorized 




reAuthorization_ 
Requested 



stopAkTiming 
(akList) 



permanent_ 
Rejection 



'disable all 
forwarding 
of AP traffic" 



StopTck 



stopAkTiming 
(akList) 



RlcAuthReject 
(authReject) 



StopTck 



set(now + 
AuthRejectWait_ 
Timeout, 
r_AuthRequestRetry 



RlcAuthReject 
(authReject) 



AuthRcjcctWait 



) x 



akRecord := 
prcpAkRecord 
(defAuthKey, 
defAkLifeTi me, 
akSeqNo) 







authRe 
prepAu 
(authRcq, 


ply := 
h Reply 
akRecord) 



RlcAuthRcply 
(authReply) 



AK updated 



AKti ming 
(hkRecord ! akLifcTimd) 



akRccordlakPid 
:= offspring 



akList := addAk 
(akList, akRecord) 



said :- authReply 
!said 



akSeqNo := 
incAkSN(akSeqNo) 



AuthCompl 
(authReply! 
akSeqNo) 



authlnvalid :- 
prepAuthlnv(onc) 



RlcAuthln valid 
(authlnvalid) 
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process type AP_Authorization 



7(7) 



AK expired 



^ Authorized ^ 



AkExpired 



akList :- 
rcmovcAk 
(akList) 




This needs checking since there maybe no 
active AKs for some time???? 



This should not happen since RlcAuthRcq 
should come before the latest AK expires? 



A new RlcAuthReq would be handled, but 
it's lifetime would start later then the latest 
valid AK expired 

This should mean that RlcTckReq would 
not be authenticated and would result 
in Authlnvalid message ?????? 
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2 AT SC 



(UL_PKM_AUTH) 



PKM 



] [< 



(DL_PKM_AUTH) 



process type AT_Authorization 



5 



1(6) 



child 



^(fromTEK)J 



^(toTEK)] 
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process type AT_Authorization 



2(6) 



TIMER T_AuthReq := T_AuthReqDuration; |\ 
TIMER T_AuthRequestRetry: ^ 



DCL authManufacturerlnfo RlcAuthManufacturcrlnfo; I 
/» fields: 

manufacturer X509certincate */ 

DCL authReq RlcAuthReq; 
/» fields: 

AfX509certificate, AtPublicKey, Manufacturerld */ 

DCL authReply RlcAuIhReply; 
/» fields: 

AuIhKey, AkSeqNo, AkLifeTime, Said "/ 

DCL authRcjcct RlcAuthReject: 
/» fields: 

AuthErrorCodc, ErrorInfoText[Optional]*/ 

DCL authlnvalid RlcAuthlnvalid; 
/» fields: 

authlnvalidErrorCode 
errorlnfoText OPTIONAL */ 



DCL said Said; 

DCL currentAkSeqNo AkSeqNo: 



DCL akList AkList; 
DCL akRecord AkRecord; 



exported procedure Saidlnvalid; |\ 



start; 
return; 
endprocedure; 
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process type AT_Authorization 



3(6) 



Starting 



Starting 



] c 



authManufa_ 
cturerlnfo :- 
I repAuthManInfo(on< ) 



RlcAuthManufa_ 
cturerlnfo 
(authManufa_ 
cturerlnfo) 



authReq :- 
prcpAuthRcq(onc) 



RlcAuthRcq 
(authReq) 



(T_AuthReq) 



HZ 



X 



Regular authorization 
renewal 



T_Auth_ 
RequestRetry 



RlcAuthRcq 
(authReq) 



reset(T_Auth_ 
RequestRetry) 



(T_AuthRcq) 



Exception 

AP decided that 
current authKey 
has become invalid 



X \ Rl cAuthln valid / 

\. (authlnvalid) \^ 



Exception 

AT could not 
authenticate 
Rl cTekAll ocation 
or RlcTekRcject 



AuthPend 

/* Traffic keys 
generation 
suspended until 
new AK 
becomes 
awailable */ 



reset(T_Auth_ 
RequestRetry) 



RlcAuthReq 
(authReq) 



(T_AuthReq) 
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process type AT_Authorization 



4(6) 



RlcAuthReply 
(authReply) 



reset 
(T_AuthReq) 



akRecord :- 

saveAk 
(authReply) 



akList :- 
cmptyAkList 



akList := addAk 
(akList, akRecord) 



said :- authReply 
!said 



currentAkSeqNo :- 
authReply! akSeqNo 



Authorized 
(said, authReply 
akSeqNo) 



t (now+calcAkLifcTi 
(authReply), 
r_AuthRequestRetry 



^ Authorized ^ 



Exception 



Reply not received 
in time 



RlcAuthReject 
(authReject) 




pcrmancnt_ 
Rejection 



'disable all 
forwarding 
of AT traffic' 



re Author ization_ 
Requested 



set(now + 
AuthRejccfWait_ 
Timeout, 
["_AuthRequcstRetry 



akList :- 
emptyAkList 



StopTek 



> 



X 



StopTek 



^ AuthRcjectWait ^ 



The parent Authorization 
FSM shall stop all of its 
child TEKFSMs when 
the AT receives from the 
APan RlcAuthReject 
message during a 
reauthorization process. 



T_AuthReq 



RlcAuthRcq 
(authReq) 



(T_AuthReq) 



Exception 

RlcAuthRcq 

not received by AP 

RlcAuthCmd retransmitted 



reset 
(T_AuthReq) 



authManufa_ 
cturerlnfo :- 
I repAuthManInfo(on< 



Rl cAuthManuf aj 
cturerlnfo 
(authManufa_ 
cturerlnfo) 



authReq :- 
prepAuthReq(one) 



RlcAuthReq 
(authReq) 
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process type AT_Authorization 



5(6) 



RlcAuthReply 
(authReply) 



reset 
(T_AuthReq) 



akRecord :- 

saveAk 
(authReply) 



akList :- 
removeAk 
(akList) 



akList := addAk 
(akList, akRecord) 



current AkSeqNo :- 
authReply! akSeqNo 



AuthCompl 
(authReply! 
akSeqNo) 



t (now+calcAkLifcTi 
(authReply), 
T_AuthRequestRetry 



Exception 

AP decided that 
current authKey 
has become invalid 



Exception 



Reply not recei vcd 
in time 



RlcAuthln valid, 
(authln valid) 



akList :- 
emptyAkList 



(T_AuthReq) 



RlcAuthReq 
(authReq) 



RlcAuthReject 
(authReject) 



T_AuthReq 



reset 
(T_AuthReq) 




RlcAuthReq 
(authReq) 



authReject 
<uithErrorCoj 



permanent_ 
Rejection 



'disable all 
forwarding 
of AT traffic' 



(T_AuthRcq) 



reAuthorization_ 
Requested 



set(now + 
AuthRejcctWait_ 
Timeout, 
r_AuthRcquestRetry 



StopTek 



StopTek 



akList :- 
emptyAkList 



AuthRejcctWait 



c 
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process type AT_Authorization 



6(6) 




Waiting before a 
new authorisation 
may be accepted 



( AuthRejectWait j 



Added so that 
all signals received 
while in this state 
are discarded 



• < 


T_Auth_ / 
RcquestRctry 




/ 


N 




AuthRejectWait | 


I S,m '" S J 
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E.5.3 AP TEK 



authAp 



> ^(fromTEKap)J 
J(toTEKap)] 



process type AP_TEK 



tekTimeLeft 



stopTekTiming 



stopFirstTekTiming 



exported procedure akSeqNoContirmcd; [\ 
fpar akSn AkSeqNo; 
returns AkConfirmed; 
start; 

decision (hmacScqNo- akSn); 

(true): return (akConfirmed); 

(false): return (akNotConfirmed); 
enddecision; 
end procedure; 



imported procedure tckSeqNoConfirmed; 
fpar TekSeqNo; 
returns TekConfirmed ; 



(UL_PKM_TEK) 



tekt 



TekExpired, I 
TekTimeLeft I 



gctTekTimcLcft I 



tek 



1(9) 



^Invalid J 
^^Kcys, Stopltj 



PKM 



(DL_PKM_TEK) 
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process type AP_TEK 




o 



2(9) 



DCL tckReq 
DCL tckAllocation 
DCL tckReject 

DCL tekSN 
DCL tekList 

DCL activcDLsn 
DCL activcULsn 

DCL tckLifeTime 



RlcTckReq; 

RlcTekAllocation; 
RlcTekReject; 

TekSeqNo; 
TekList; 

TekSeqNo; 
TekSeqNo; 



DCLtckRecordl, tekRecord2 TckRccord; 



DCL said 
DCL authKcy 
DCL tckln valid 
DCL tekTimeLeft 

DCL isTeklnvalid 
DCL isAkln valid 

DCL akSeqNo 
DCL hmacSeqNo 



Said; 
AuthKey; 
RlcTekln valid; 
Integer; 

IsTeklnvalid :- maxTeklnvalid; 
IsAklnvalid ;- maxAklnvalid; 

AkScqNo; /* seqNuniReccivcd from Auth */ 
AkSeqNo; /* latest AkSeqNinn derived from hmac */ 







tekList :^ 
emptyTekList 






tekSN ;= 
any(TekSeqNo) 


N 




( S,m '" e J 



imported procedure SaidApInvalid 



DCL tcstData Boolean := false; 
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process type AP_TEK 3(9) 



Just to make sure they 
arc not equal initialy 



^ Starting J f Starting ^ 



Authorized 
(said, akSeqNo? 



hmacSeqNo :- 
incAkSN(akSeqNo) 



StopTek 



ETSI 



260 



ETSI TS 102 000 V1.3.1 (2002-12) 



process type AP_TEK 



4(9) 



InitialTEK 
I 



RlcTck2Rcq 
(tekReq) 



isAklnvalid :- 
dccr(isAkIn valid) 




rcqRejected 



tekReject := 
prcpTckReject 
(said, tekSN) 



| RlcTckReject 

I (tekReject) / 



rcqAcccpti 



tekRecordl :- 
newTekRccord 
(tekReq, 
detTekLT. tekSN) 



tekS 
any(Tel 


N:= 
SeqNo) 






stopTel 
(tekl 


Timing 

J St) 







tekAllo 
prepTek/ 
(tekRe 


atitm :- 
vllocation 
cordl) 



R] cTckAll ocation 
(tckAllocation) 



StopTek 



tekRecord2 := 
newTekRccord 

(tekReq, 
2*defTekLT, 
incSN(tckSN)) 



Stoplt 



tckAllocation :- 
prepTekAll ocation 
(tekRecord2) 



SaidApInvalid 



Rl cTckAll ocation 
(tekAllocation) 



TckTiming 
(detTekLT) 



tekRecordl ItckPid 
:= offspring 



TckTiming 
(2* defTekLT) 



tekRecord2!tekPid 
:= offspring 



tekList := addTek 
[tekList, tekRecordl) 



tekList := addTek 
(tekList, tckRecord2) 



activeDLsn := 
ekList(lst)!tekSeqN< 



active ULsn :- 
i ;kList(2nd)!tekSeqN 



tekSN := 
incSN 
(tekSN) 



Operational 



RlcTekReq 
(tekReq) 



StopTek 



stopTekTiming 
(tekList) 



Stoplt 



Starting 



X 
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process type AP_TEK 



5(9) 



Operational 



RlcTekReq 
(tekRe q) 



isAklnvalid :- 
dccr(isAklnvalid) 




Operation al 



rcqRcjcctcd 



tckReject := 
prcpTekRcjcct 
(said, tekSN) 



rcqAcccptcd 



Keys 

(activeULsn , 
activcDLsn) 



RlcTckRcjcct 
(tckReject) 




stopTck 
(tekl 


Timing 
List) 






SaidAp 


Invalid 



tekSeqNoCon tir mcd 
(tekList(2nd) ItekSeqNo) 



tckNotConf i rmcd 



ckTimcLcft := CALI , 

tckTimeLeft 
(tekList(2nd)!tekPid; 



tekConfirr led 



tekSN := 
incSN 
(tekSN) 



tekRecordl :- 
ncwTckRccord 
(tckReq, 
tckTimeLeft , tekSN 



activeDLsn := 
5kIist(2nd)!tekSeqN 







tekAllo 
prepTck/ 
(tekRe 


ation := 
allocation 
cordl) 



X 



ckTimcLeft := CALI 

tekTimeLeft 
(tekList(2nd)!tekPid) 



RJ cTckAll ocation 
(tckAllocation) 



Keys 

(activeULsn, 
activcDLsn) 



tekRecordl := 
newTekRccord 

(tekReq, 
tckTimeLeft + 
dciTekLT. tekSN) 



^ Operational J 







tekAllo 
prepTck/ 
(tekRe 


ation := 
vl location 
cordl) 



RlcTckAll ocation 
(tckAllocation) 



IL 



stopFirst_ 
TekTiming 
(tekList) 



TekTiming 
(tekRccord 1 ! 



tekRecordl ItckPid 
:= offspring 



tekList :- addTek 
(tekList, tekRecordl 



activcDLsn :- 
:ekList(lst)!tekSeqN( 



activeULsn :- 
;kList(2nd)!tekSeqNb 



Keys 

(activeULsn, 
activeDLsn) 



^ Operational ^ 
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process type AP_TEK 



6(9) 



Operational 



The key lifetime 
has expired 



TekExpircd 



Stoplt 



tekln valid :- 
prepTekln valid 
(said, teklist(Ist)! 
tekSeqNo) 



stopTekTiming 
(tekList) 



RlcTekl rival id 
(tekln valid) 



> 



StopTek 



stopTekTimirtg 
(tekList) 



Stoplt 



( Starting J 
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process type AP_TEK 



Extract AK seqNo 
used in TekReq 





hmacScqNo :- 
readHmac 
(tckReq) 










ra Rejected 



tckReject := 
prcpTckRcjcct 
(said, tekSN) 



RlcTckRcjcct 
(tckReject) 



tckS 
any(Te 


N:= 
SeqNo) 






stopTek 
(tckl 


Timing 
Jst) 



StopTek 



Stoplt 



SaidApInvalid 



X 



Operation 



D 



RlcTek2Req 
(tekReq) 



stopTekTiming 
(tekList) 



isAklnvalid :- 
decr(isAklnvalid) 




rcqAcccptcd 



stopTek 
(tek. 


Timing 
List) 







tekRecordl :— 
newTekRecord 
(tekReq, 
detTekLT. tekSN) 







tekAllo 
prepTek/ 
(tekRe 


ation :- 
Ulocation 
oordl) 



Rl cTekAll oc ation 
(tekAllocation) 



tekRecord2 :- 
newTekRecord 

(tekReq, 
2*defTekLT, 
incSN(tckSN)) 



tekAllocation :- 
prepTekAllocation 
(tekRecord2) 



RlcTekAllocation 
(tekAllocation) 



TekTiming 
(defTckLf) 



tekRecordl ItckPid 
:= offspring 



TekTiming 
(2* defTekLT} 



tekRccord2!tekPid 
:= offspring 



tekList :- addTek 
(tekList, tekRccord I 



tekList :- addTek 
(tekList, tekRccord2) 



activeDLsn :- 
ekList(lst)!tekSeqNi 



activeULsn :- 
skList(2nd)!tekSeqN 



tekSN := 
incSN(incSN 
(tekSN)) 



Keys 

(activeULsn, 
activeDLsn) 



Operational 



^ Operatiooal ^ 



7(9) 



AuthCompl 
(akScqNo) 



f \ \ 

I Operational J (activeULsn. > 

\ J activeDLsn) / 



OpReanthWait 
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process type AP_TEK 8(9) 



AuthCompl 
(akSeqNo) 



StopTck 



stopTekTiming 
(tckList) 



Stoplt 



Starting 



The key lifetime 
has expired 



TekExpircd 



stopTekTiming 
(teklist) 



Stoplt 



RIcTekReq 
(tckReq) 



] c 



RlcTek2Rcq 
(tekReq) 
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process type AP_TEK 9(9) 



RlcTek2Rcq 
(tekRcq) 



RlcTekRcq 
(tekRcq) 



( OpRcauthWait l ( 



OpRcauthWait 



OpRcauthWait 



AuthCompl 
(akSeqNo) 



Keys 

(activeULsn, 
activeDLsn) 



Operational 



StopTek 



> 



stopTekTiming 
(tekList) 



Stoplt 



Starting 



The key lifetime 
has expired 



TekExpired 



tekln valid :- 
prepTekln valid 
(said, teklist(lst)! 
tekSeqNo) 



stopTekTiming 
(tekList) 



RlcTeklnvalid 
(tekln valid) 



Stoplt 



tekln valid :- 
prepTekln valid 
(said, teklist(lst)! 
tekSeqNo) 



stopTekTiming 
(tekList) 



RlcTeklnvalid 
(tekln valid) 



Stoplt 



J ^ ReauthWait l f 



ETSI 



266 



ETSI TS 102 000 V1.3.1 (2002-12) 



5.4 AT TEK 



auth 



/ ^(fromTEK)J 
J(toTEK)] 



process type TEK 



1(9) 



PKM 

£(UL_PKM_TEK)] £(DL_PKM_TEK)J 



tek 

^Kcys, Stopltj ^InvalidJ 
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process type TEK 



DCL tekReq 
/» fileds: Said */ 



RkTekReq; 



DCL tckAllocation RlcTckAllocation; 
/» fileds: 

said, tekl, teklLifeTime, teklSeqNo, 
hmac, initializationStatus */ 

DCL tckReject RlcTekReject; 
/» fileds: 

tckScqNo, said. tckEnorCode, 
errorlnfoText OPTIONAL, hmacDigesl »/ 

DCL tcklnvalid RlcTeklnvalid; 
/» fileds: 

tckScqNo, said. tckEnorCode, 
errorlnfoText OPTIONAL, hmacDigesl */ 

DCL authKey AuthKey; 

/* the key to be used for decrypting TekKcy info */ 



CD 



2(9) 







teklist := 
emptyTekList 




* 



( Starting ^ 



DCL activeDLsn 
DCL activeULsn 

DCL said 
DCL tckList 
DCLtckRecordl 

DCL isAkln valid 
DCL isTeklnvalid 

DCL akSeqNo 



TekSeqNo; 
TekSeqNo; 

Said; 
TekList; 
TekRecord; 

IsAklnvalid :- maxAkln valid; 
IsTeklnvalid :- maxTcklnvalid: 

AkSeqNo; 



TIMER T_TekReq := T_TekRcqDuration: N 
TIMER T_Tek2Req := T_Tek2ReqDuration 



/* Amount of time before key */ 
/* is scheduled to expire that the AT 
/* starts asking for new keys. */ 

TIMER TEKrefreshTimer; 
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process type TEK 3(9) 



First authorization 
complete 



Starting 



Authorized 
(said, akSeqNo} 1 



tekReq := 
pre }TckRcq(akSeqNo, s lid) 



RlcTck2Req 
(tekReq) 



set(T_Tck2Req) 



Exception 



Authorization 
rejected 



StopTek 



tekList := 
emptyTekList 



J (_ 



Stalling 



J L 



Starting 
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process type TEK 



4(9) 



: Normal 

: First allocation 



RlcTckAllocati 
(tckAl location) 



isAklnvalid :- 
decr(isAkIn valid) 




tekList := addTek 
(teklist, tekRccordl 



: Needs to be ignored 
• since new key exchange 
: is in progress 



• Exception 



RlcTekln valid 
(tekln valid) 



hmacNotValid 



reset( 
T_Tek2Req) 



( OpWait J ^ InitialTEK 1 



: Exeception 
: First 

■ RlcTekAllocation 
i not arrived in time 



reset( 
T_Tek2Req) 



OpReauthWait 



T_Tek2Req 



tekReq := 
pre iTekRcqfakSeqNo, s iid) 



RlcTek2Req 
(tekReq) 



set( 
T_Tek2Req) 



StopTek «^ 






reset( 
T_Tck2Req) 






tekList :- 
emptyTckList 







Starting 



: Exception 
: Rejected 



RlcTekReject 
(tekReject) 



X 
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process type TEK 



5(9) 



Normal 

RlcTckAl location 



OpWait 



Exception 



Second RlcTekAllocation 
not arrived in time 



RlcTckAl locati 
(tckAl location) 



isAklnvalid :- 
decr(isAk!n valid) 




hmacNotValid 



reset 
(T_Tek2Rcq) 



reset( 
T_Tek2Rcq) 



tekRecordl := 
savcTekRecord 
(tckAllocation) 



tekList :- addTek 
(tekList, tekRccord 1 



activeDLsn :- 
ekList(lst)!tekSeqNi 



activeULsn := 
;kList(2nd)!tekSeqN 



s :t(now + calcLifcTin e 
(tekList(2nd) 
ItekLifcTime), 
TEKrcfreshTi mer) 



Keys 

(activeULsn, 
activeDLsn) 



OpWait 



^ Operational J 



T_Tek2Req 



tekReq :- 
pre >TckReq(akSeqNo : s lid) 



RlcTck2Req 
(tekReq) 



set( 
T_Tek2Rcq) 



tekList := 
emptyTekList 



reset( 
T_Tek2Req) 



OpRcauthWait 



StopTek 



reset( 
TEKrctreshTimer) 



tekList := 
emptyTekList 



reset( 
T_Tek2Rcq) 



Starting 
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process type TEK 



6(9) 



OpRcauthWait 



: Reauthorization 
■ completed 



( OpReauthWait 1 



: Exception 



: Reauthorization 
■ rejected 



AuthCompl 
(akSeqNo) 



tekReq :- 
pre iTekRcqfakScqNo, s id) 



RlcTck2Req 
(tekReq) 



reset( 
TEKrefreshTimer) 



set(T_Tek2Req) 



( InitialTEK 1 



StopTek «^ 






reset( 
TEKrefreshTimer) 






tckList := 
emptyTekList 







^ Starting ^ 



RlcTekAllocati; 
(tekAllocation) 



OpReauthWait 
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process type TEK 



7(9) 



: Time to refresh 
» the key 



Operation al 



TEKrefreshTi 



ffler 



tekReq :- 
pre }TekRcq(akSeqNo, s lid) 



RlcTckReq 
(tekReq) 



Keys 

(activeULsn, 
activcDLsn) 



set( T_TekReq) 



RekeyWait 



Operational 



: Exception 

: This is received from AP 

■ ->seqNum of tratic encryption key 

i used in uplink was wrong 



RlcTekln valid 
(tekln valid) 



StopTek 



Stoplt 



teklist := 
emptyTckList 



reset( 
TEKrcfreshTimer) 



reset 

(TEKrefreshTi mcr) 



tekList := 
emptyTckList 



Stoplt 



tekReq := 
pre iTekReq(akSeqNo, s id) 



RlcTek2Req 
(tekReq) 



set(T_Tck2Rcq) 



^ InitialTEK ^ 
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process type TEK 



8(9) 



Normal 

RlcTckAl location 



RekeyWait 



RlcTckAl locati 
(tckAl location) 



isAklnvalid :- 
decr(isAk!n valid) 



T_TekRcq 



StopTek 



tekReq :- 
pre )TekRcq(akScqNo, s Lid) 



AuthPcnd <^ 


Invalid ^ 


RlcTcklnvalid X 
(tckln valid) %. 






' > 







teklist := 
cmptyTckList 



hmacNotValid 



resetf 
T_TckReq) 



RekeyWait 



Operational 



Keys 

(activeULsn, 
activeDLsn) 



reset 
(T_TekRcq) 



tekRecordl :- 
saveTckRecord 
(tekAl location) 



teklist :- addTek 
(tekList, tekRecordl) 



activeDLsn := 
ekList(lst)!tekSeqN( 



activeULsn :- 
:kList(2nd)!tekScqN 



s ;t(now + calcLifeTin e 
(tekList(2nd) 
ItekLifcTime), 
TEKrcfreshTimer) 



Keys 

(activeULsn, 
activeDLsn) 



RlcTekRcq 
(tekReq) 



tekList := 
cmptyTckList 



T_TekRcq) 



reset( 
T_TekReq) 



Stoplt 



RekeyWait 



Starting 



RekeyWait 






RlcTekRejcct JT 
(tekRejcct) \ 






Saidlnvalid 


\ 


/ 



reset( 
T_TekRcq) 



Keys 

(activeULsn, 
activeDLsn) 



J 



RekeyReauthWait 



Exception 
TekReq rejected 



Use the new AK 



tekReq := 
pre iTekReq(akSeqNo, s iid) 



RlcTek2Req 
(tekReq) 



Stoplt 



set(T_Tek2Rcq) 



reset( 
T_TekReq) 



^ RekeyWait | 







AuthComp] / 
(akSeqNo) N. 







RekeyWait 
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process type TEK 9(9) 



RckcyReauthWait 









StopTek «^ 






Stopit \ 






tckList := 
emptyTekList 


\ 




( 

Starting 

V 1 



AuthCompl 
(akSeqNo) 



Keys 

(activeULsn, 
activeDLsn) 



tekReq := 
pre >TekReq(akScqNo, s rid) 



RlcTckReq 
(tekReq) 



(T_TekRcq) 



sis 

^ RekeyWait ^ 



RlcTeklnvalid / 
(tekln valid) V 






i — 


tekList := 
emptyTekList 






Stopit \ 






( 

OpReauthWait 



RekcyRcauthWait 
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Annex F (informative): 

ASN.1 interpretation guidelines 

ASN. 1 module contains a number of user defined types which have the form: 

X ::=Y 

where X represents the type that is defined and Y is another user defined type or one of the basic ASN. 1 types. Basic 
ASN. 1 types used in this module are INTEGER and OCTET STRING. 

ASN. 1 has also a way to define values and give those values a name. A statement 

x X ::= 1 

defines x to be of type X and having a value 1. Note that ASN.l is case sensitive, where basic types and keyword have 
to be spelled exactly as defined by ASN. 1 rules and all user defined types have to start with a capital letter. Words 
starting with lower case letters can only be used for naming components of types and values. 



HAprotocolPrimitives 
DEFINITIONS 


ASN.1 module name 


AUTOMATIC TAGS 


When values are transmitted tags (values) need to be inserted by the 
encoder so that the receiving side know what is being transmitted. 
This statement says that values needed for this will be generated 
automatically. 


BEGIN 


ASN.1 keyword indication the beginning of the module 


EXPORTS 


The statement listing types defined in this module that are visible 
outside of this module 


INTEGER (64 . . 128) 


This specifies the type that is in principle integer but the range of 
values is restricted to 64 through 128 


(0 | 5 . . 63) 


Another way of specifying the range. Zero and values from 5 to 63 are 
allowed. 


ENUMERATED { 
fdd (0), 
tdd (1) } 


Type definition where one of the two named values can be used. Note 
that in the HA DLC specification these values are explicitly said to be 
normative. 


INTEGER {phyModeSetl (1), 
phyModeSet2 (2)} (0..15) 


Here the values can go from to 15 but two of them are named with 
the intention to have a specific meaning within a system. 


OCTET STRING 


A string of octets. 


(SIZE(128) ) 


SIZE keyword can be used to limit the length of some list. In this 
example this is a fixed length of 128 elements of the list. 


(SIZE (1 . . 128) ) 


This is a variable length list which can have from 1 to 128 number of 
elements. 


SEQUENCE (SIZE (1. .50) ) OF X 


SEQUENCE OF defines a list of elements of type X. The size 
constraint is explained above. 


SEQUENCE { 
x X, 

y y } 


The type means that two component exist, where for each of them the 
name of the component and its type are given. 


SEQUENCE { 
x X, 

y Y OPTIONAL} 


Unlike above where both components are mandatory, here the 
component y may be omitted. 


CHOICE { 
x X, 

y y } 


Choice is a type that can hold one of the components listed at the 
particular point in time. 




In most cases the beginning of the comment in ASN.1 . The comment 
goes until the end of the line or until another pair of hyphens on the 
same line. 


MacManagementMessage ::= 

CHOICE { 

— all messages 

} 


In this module, this is the root of all type definitions. It represents the 
type of the message that can be transmitted, this being one of those 
listed choices. 


END 


The keyword that ends the module definition. 



ETSI 



276 



ETSI TS 102 000 V1.3.1 (2002-12) 



Annex G (informative): 
List of all PHY parameters 

Table G.l gives specifications from TS 101 999 [1], reported here for easy reference. In any case of existing or 
perceived difference in contents between the present document and TS 101 999 [1], the correct specification is that 
given in TS 101 999 [1]. 



Table G.1 : Complete list of PHY parameters 



Parameter 


Value or range 


Channel spacing (UL and DL) 


28 MHz 


Max number of ATs per carrier/sector 


254/256 


BER 


10E-11 






Rain fading for HA 


20 dB/s 






MAC PDU length 


Downlink: 54 bytes 
Uplink: 55 or 12 bytes 


Number of PDU per FEC block 


1 or up to 4 


Control zone length 


Variable (n x 30 bytes) 


Scrambler 


Length 2 15 -1 with "100101010000000" initial, state 


Inner mandatory FEC coding 


Punctured Convolutional with rate 1/2, 2/3, 5/6, 7/8 and 1 


Tail bits for the inner mandatory FEC coding 


6 bits (per FEC block) 


Outer mandatory FEC scheme 


Reed Solomon (k + 16, k, t = 8) 


Optional product turbo code (PTC) 


Only UL (encoder in AT and decoder in AP) 
with 24 bit CRC 


Means for ARQ 


Only for the UL vian RS or CRC in case of PTC 


Number of PHY mode sets 


2 (one optional) 


Number of PHY modes per set 


4 


Modulation 


4-16 QAM (optional) for UL and 4-16 and 64QAM (optional) for 
the DL with constant rms. 


Mapping 


Gray 


Types of UL bursts 


Three types of bursts: Long burst (data or long signalling), short 
burst (short signalling) and ranging burst 


Preamble length 


TDM DL preamble: 32 symbols 
TDMA DL preamble: 16 symbols 
ULTDMA: 16 or 32 symbols 
UL ranging burst: 32 symbols 


Roll-off factor 


0,25 


Symbol clock rate 


22,4 MHz with ±8 ppm APT clock accuracy 






Frame length 


1 ms 


Frame offset 


0,40 to 1 ms 


Load levelling time/carrier recovery time after 
short link interruption 


< 100 ms 


UL ramping up /down time 


8 symbols 


TDD switching time 


48 symbols 


H-FDD switching time 


480 symbols 


Extended guard time 


up to 80 ms 


Timing advance correction during initialization 


to 80 us with 1/4 symbol granularity 


Timing advance correction, fine tuning 


[-2, 2] symbol with 1/4 symbol granularity 


Report period time 


[50, 200] ms with 50 ms granularity 


PHY processing delay 


200 symbols (without pipelining) 






AT transmit power margin 


0- 12 dB on the top, with 0,25 dB granularity 


AT C/(N+I) measurement 


4 - 40 dB with 0,25 dB granularity 


AT receiver dynamic range 


60 dB minimum 


Measured received power in AT 


[-88, -28] dBm (for minimal dynamic) with 0,25 dB granularity 


APT receiver dynamic range 


30 dB minimum 


Measured received power in AP 


[-86,-56] dBm (for minimal dynamic) 


UL power control 


40 dB dynamic minimum 


AT transmit power measurement 


[-26, 14] dBm (for minimal dynamic) with 1 dB granularity 
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Parameter 


Value or range 


Uplink power steps (increments) 


[-4, +4] dB with 0,25 dB granularity, 
during initialization up to [-8, +8] dB 


DL dynamic power control (optional) 


4 dB dynamic for APT-class-1 
7 dB dynamic for APT-class-2 
\ u ok oynamic ror Ar i -ciass-o 


It I /~\ \ a //""v ^ o+rtK^o ( iv~\r^^f\ yy~\ s\ rite* \ 

ui_ power steps (incrernenisj 


[- 1 , 1 J QD 


ul sialic power selling ^optional] 


i u od dynamic 






oarrier Trequencies 


; ; 

> 1 1 GHz with ±8 ppm accuracy for APT and ±1 ppm relative 
accuracy for AT 


Frequency resolution 


1 MHz, except 0,25 MHz for 28 GHz 


Antenna base station 


TM4 specifications (e.g. 45, 60 and 90°) 


Antenna terminal 


TM4 specifications 


Output power at maximum setting 


1 5 dBm for APT and 1 4 dBm for AT 


Max. EIRP AP (Class-1) 


33 dBmi + 3 dB accuracy 


Max. EIRP AT (42 GHz) 


51 dBmi + 3 dB accuracy 


Modulation Accuracy: EVM 


1 2 % and 6 % for 4-QAM, 1 6-QAM (without equalization) 
1 %, 3 % and 1 ,5 % for 4-QAM, 1 6-QAM and 64-QAM 
(without equalization) 


NFD-Figures 


35,5 dB for the DL 
29 dB for the UL 


UL carrier on/off (time mask) 
PHY mode: PHY1 
PHY mode: PHY2 
PHY mode: PHY3 


FDD H-FDD TDD 
38 dB 30 dB 30 dB 
42 dB 34 dB 34 dB 
48 dB 40 dB 40 dB 






Performance monitoring 


According to ITU-T Recommendations G.826 [4], G.821 [3], 
G.827 [5] and M.2100 [6] 
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